00:34 <FromGitter> <michael-swan> With `BitArray`, is there an efficient way to extract a range of a BitArray as an Int32 or something?

00:35 <FromGitter> <michael-swan> I was looking through the interface and it looks like you can at best get back another BitArray if you extract a range

00:36 <FromGitter> <michael-swan> like `bits[0..6]` would give you another BitArray but I would like to get the Int32 corresponding with those bits

00:38 <FromGitter> <michael-swan> I wish there was like a `#to_i`-like function which could return `UInt32?` such that it would give `nil` if the `BitArray` is too large to have its bits fit in a `UInt32`

00:40 <FromGitter> <michael-swan> Is there a way that I can extend or subclass the stdlib `BitArray` to add such functionality?

00:49 <FromGitter> <jrei:matrix.org> Why have you a `BitArray` in the first place?

00:50 <FromGitter> <michael-swan> I'm decoding RISC-V instructions

00:50 <FromGitter> <michael-swan> And I want to break out sections of the instructions, e.g. opcode, funct3, funct7, rd, rs1, rs2, etc.

00:51 <FromGitter> <jrei:matrix.org> So, you can transform this bits to bytes, then use https://crystal-lang.org/api/1.6.2/IO/ByteFormat/LittleEndian.html

00:54 <FromGitter> <michael-swan> Okay, that's a good start, thanks. I think I might be able to do something like: ⏎ ⏎ ```funct3 = IO::ByteFormat::LittleEndian.decode(UInt8, bits[12..14].to_slice)``` [https://gitter.im/crystal-lang/crystal?at=63af8830fb195421bd6052e5]

00:54 <FromGitter> <michael-swan> I didn't test that but looks like something like that would do, though I have to imagine that this is a pretty inefficient way of doing things

00:54 <FromGitter> <michael-swan> I might just have to break it out the old-fashion way

00:55 <FromGitter> <michael-swan> That's already a little complicated

00:56 <FromGitter> <jrei:matrix.org> why inefficient? Not that much

00:56 <FromGitter> <jrei:matrix.org> some structs are created, but that's it

00:58 <FromGitter> <michael-swan> I'll have to experiment, really is a function of how much inlining and simplification the compiler can do with that. This is an instruction decoder and it will be a pretty hot function for my purposes

00:58 <FromGitter> <michael-swan> I'm trying to write an emulator

00:58 <FromGitter> <michael-swan> Instruction decoding needs to be fast but I'm also trying to take advantages of the expressive features of this language

00:58 <FromGitter> <jrei:matrix.org> I guess make it work, then make it fast(er)

00:58 <FromGitter> <michael-swan> Yeah

00:59 <FromGitter> <michael-swan> I'll experiment. Interestingly Godbolt has Crystal support

00:59 <FromGitter> <michael-swan> So I could run some tests there

00:59 <FromGitter> <jrei:matrix.org> sometimes code seems inefficient but LLVM can optimize out things at times

01:00 <FromGitter> <michael-swan> Gotcha

01:00 <FromGitter> <michael-swan> Yeah this language is pretty sick. I used to write Ruby in high school and then gave it up because it was ungodly slow.

01:01 <FromGitter> <michael-swan> My hope is that there is enough smarts in this compiler to be usable for my purposes, i.e. emulation

01:01 <FromGitter> <jrei:matrix.org> Perhaps you could `IO::Memory`?

01:01 <FromGitter> <michael-swan> Yeah, that might be the move for this

01:02 <FromGitter> <jrei:matrix.org> if what you want is to buffer this instructions, then clear the buffer and reuse it to store subsequent instructions

01:02 <FromGitter> <michael-swan> I mean, that's likely how this information will be stored anyways. I haven't really even considered how I should best represent my volatile memory. `IO::Memory` is likely the move

01:04 <FromGitter> <jrei:matrix.org> but you just have to store bits, not bytes 🤔

01:08 <FromGitter> <michael-swan> Well I mean, the bits thing is just meant as a neat abstraction. If I could get away with thinking of my instructions in terms of bits without having to perform a series of Int32 to Int32 transformations such as bit-shifts and AND bit-masks etc.

01:08 <FromGitter> <michael-swan> Like, that'd be neat if I could get away with writing code in that way at no cost

01:08 <FromGitter> <michael-swan> BitArray seemed to fit that ask

01:08 <FromGitter> <jrei:matrix.org> Indeed

01:09 <FromGitter> <jrei:matrix.org> Also note there is a pointer available at `bits.@bits`

01:09 <FromGitter> <michael-swan> But I don't want to make any assumptions. I'd rather learn early what the hell it actually compiles too so I'm not constructing a silly house of cards

01:09 <FromGitter> <michael-swan> Oh okay

01:09 <FromGitter> <michael-swan> That's good to know

01:09 <FromGitter> <michael-swan> Can I actually reference it that way?

01:09 <FromGitter> <michael-swan> Like if `bit : BitArray` I can actually just evaluate `bits.@bits`?

01:10 <FromGitter> <michael-swan> Also, what'

01:11 <FromGitter> <michael-swan> I keep trying `crystal i` and it says it hasn't been compiled in but like why not?

01:11 <FromGitter> <jrei:matrix.org> ivars can accessed this way in the language, but it is not recommended

01:12 <FromGitter> <michael-swan> I can see why it's not recommended but definitely good to know

01:12 <FromGitter> <jrei:matrix.org> obviously getters are designed to publicly access them

01:12 <FromGitter> <michael-swan> Right

01:12 <FromGitter> <michael-swan> Also, am I able to locally extend stdlib code like this?

01:12 <FromGitter> <jrei:matrix.org> yes, can be helpful for low-level access, debugging

01:13 <FromGitter> <jrei:matrix.org> You can monkey patch and re-open objects, but that's another thing.

01:13 <FromGitter> <michael-swan> Like I can do something like ⏎ ⏎ ```class BitArray ⏎ def bits ⏎ @bits ⏎ end ⏎ end``` [https://gitter.im/crystal-lang/crystal?at=63af8cd640557a3d5c51d323]

01:14 <FromGitter> <michael-swan> I presume?

01:14 <FromGitter> <michael-swan> Assuming `BitArray` is in scope

01:14 <FromGitter> <jrei:matrix.org> doing that for stdlib has to be avoided at all cost, if can't do any other way

01:14 <FromGitter> <jrei:matrix.org> Better not monkey patching and just use `#@bits`

01:15 <FromGitter> <michael-swan> Sure, I get your point, I'm not trying to go to crazy town with my changes

01:15 <FromGitter> <michael-swan> I'm really just trying to understand the language and its rules

01:21 <FromGitter> <jrei:matrix.org> Another option is to make a custom `IO` for `IO::ByteFormat::LittleEndian.decode`, in your case a custom buffer.

01:25 <FromGitter> <jrei:matrix.org> Instructions at the root are fixed-length, what do you have at first before all of this as an input?

01:28 <FromGitter> <michael-swan> I'm not sure what you're asking. RISC-V is sometimes fixed-length but they also have extensions that introduce 16-bit instructions

01:28 <FromGitter> <michael-swan> Which is something I would eventually intend to support

01:28 <FromGitter> <michael-swan> What do you mean by "what do you have at first..."?

02:00 <FromGitter> <jrei:matrix.org> So the instruction you want to decode is a sequence of 32 or 16bits, right?

02:02 <FromGitter> <jrei:matrix.org> Which are in a file I suppose, which is opened as an IO.

02:03 <FromGitter> <michael-swan> Yeah, I mean, I'll probably read in some instructions from disk while others will be written back into memory by the emulated code

02:04 <FromGitter> <michael-swan> e.g. if the emulator is running internally a Unix distro which then loads a program from its virtual hard drive

02:05 <FromGitter> <michael-swan> I mean it is essential to view this memory as a byte array sometimes and be able to decode a UInt16 or UInt32 from an offset into it, like a pointer.

02:05 <FromGitter> <michael-swan> Ideally doing so in the cheapest possible way because this will happen a whole lot

02:06 <FromGitter> <jrei:matrix.org> BitArray you meant?

02:06 <FromGitter> <michael-swan> Well it would be nice to be able to take a byte offset into memory and then view it as a BitArray, but that was not what I was just saying.

02:07 <FromGitter> <michael-swan> I was just saying that the memory abstraction is typically indexed in terms of byte offsets

02:07 <FromGitter> <michael-swan> Which means I need a way to index in a byte-wise manner

02:08 <FromGitter> <michael-swan> And sometimes I may want to get a UInt32 out of memory so there ought to be a sane and fast way to basically index into this memory and get out a four-byte word.

02:08 <FromGitter> <michael-swan> I can go one byte at a time for such operations and then piece together a endian-correct UInt32 or whatever.

02:09 <FromGitter> <michael-swan> But that is slower than an aligned word load from that offset, which is essentially what I want

02:11 <FromGitter> <michael-swan> Similarly, if I could view chunks I extract from memory in a bit-wise fashion, without incurring major overhead, that'd be nice though I suspect any such abstraction will necessarily break things down bit by bit and wouldn't be optimized to the bit shift and bit masking operations that would be optimal

02:13 <FromGitter> <jrei:matrix.org> I think it may be the way to go to use operations on Bytes, without BitArray

02:14 <FromGitter> <michael-swan> I suspect that is so