More testing around 16 bit values discovers problems

[omarandlorraine]

I've added a simple unit test: Put a value into register X and get it back out. Check they're the same.

This test fails. I've yet to find out why.

[LoganDark]

Could it be because of xl and xh? Are those stored separately from x itself, or somehow updated inconsistently?

[omarandlorraine]

Could it be because of xl and xh? Are those stored separately from x itself, or somehow updated inconsistently?

That's exactly it. When I store X, it chops up the bytes to store them, and then getting X means reassembling the bytes. But I was doing this in a stupid way. Here are some commits which correct the problem.

Inartful code though. I'll refactor before merging into master.

[LoganDark]

Alright, that would do it...

[LoganDark]

Inartful code though

Shouldn't you have methods that get/update registers, so xh and xl can be stored to / retrieved from x itself?

[omarandlorraine]

Shouldn't you have methods that get/update registers, so xh and xl can be stored to / retrieved from x itself?

Well, it's different from a traditional emulator because it needs to be able to leave registers undefined. So what if xh has a value but xl doesn't. That would mean X does not have a value. So that's why there's this chopping up and reassembling. Maybe I should've gone for valgrind's approach of masking out parts of the value instead... and if you can think of a neater/better way, I'm all ears!

[LoganDark]

Shouldn't you have methods that get/update registers, so xh and xl can be stored to / retrieved from x itself?

Well, it's different from a traditional emulator because it needs to be able to leave registers undefined. So what if xh has a value but xl doesn't. That would mean X does not have a value. So that's why there's this chopping up and reassembling. Maybe I should've gone for valgrind's approach of masking out parts of the value instead... and if you can think of a neater/better way, I'm all ears!

If you want to implement don't care bits, I think masking would be the best solution here. :)

[omarandlorraine]

If you want to implement don't care bits, I think masking would be the best solution here. :)

I think you're right. I went for the approach of using what Rust already has, which is option types. Since then I've questioned that decision. I might change my mind later.

[LoganDark]

Do you plan on simplifying strop's codebase, or documenting how it's structured? I took a look at the code, but - no offense - it just seems like a pile of stuff to me, and a ton of duplicated code.

[omarandlorraine]

Do you plan on simplifying strop's codebase, or documenting how it's structured? I took a look at the code, but - no offense - it just seems like a pile of stuff to me, and a ton of duplicated code.

I'd love to simplify it. I want it to be clean and easy to read and understand, and I know it falls short of that goal. It's grown very organically and just had bits and bobs stuck on it over time, as I'm sure is evident. Are you open to contributing?

[LoganDark]

Are you open to contributing?

That's actually why I ask; I've basically finished overhauling getargs (0.5.0 is right around the corner; just needs another audit from @j-tai), so my slot is open.

[omarandlorraine]

I've basically finished overhauling getargs

I like what you've done!

so my slot is open.

Excellent. Do you need any guidance from me?

[LoganDark]

Do you need any guidance from me?

Not sure, I haven't taken a good look at the code yet. My best guess would be "probably" as I see a ton of haskell terminology which means this is going to be real "fun" to figure out.

(The stm8 backend has me extremely scared, this looks absolutely massive and complicated)

[omarandlorraine]

That backend does maybe look massive, and bewildering, but I think it looks worse than it actually is. And I'll be here to answer any questions you have about it.

[omarandlorraine]

Regarding the Great Tidyup, I have opened issue #30 which is about this exact problem.