LDV - a better way to deal with 16-bit immediate value

[francisrstokes]

LDV - a better way to deal with 16-bit immediate value

[francisrstokes]

Hey thanks for the feedback! The encoding strategy you've proposed is really nice compared with my brute force LDV16 pseudo approach 😄. The only problem I could possibly see is that all numbers are unsigned, so it wouldn't be possible to use ADI d, -1.

That said, a lot of what you've said could definitely improve the language. Would you be interested in opening a pull request with you're proposed changes?

[hlide]

What do you mean by "all numbers are unsigned"? for a 16-bit addition, the result with signed or unsigned addends is the same. For instance, 0xFFFE + 0xFFFF = 0xFFFD. 0xFFFD can be seen as 65533 or -3, it's just a subjective viewpoint. When using ADD mode through bit 0 in OO, you just need to sign-extend the immediate value before adding it to register.

[hlide]

"opening a pull request with you're proposed changes": do you suggest for me to clone your project, do the changes and then open pull request here?

[francisrstokes]

for a 16-bit addition, the result with signed or unsigned addends is the same. For instance, 0xFFFE + 0xFFFF = 0xFFFD. 0xFFFD can be seen as 65533 or -3, it's just a subjective viewpoint

Ah good point. As for pull request, yes that's normally the easiest way.

[hlide]

hum, there are that assembler and that bf compiler... if I don't want to touch that bf compiler, I'd better to keep LDV16 but as a pseudo using the new instruction and define LDV as a pseudo as well. I could also keep INC and DEC the same way. But I would need to rename the real instruction LDV with another name - unless there is a way to have an optional third argument, that is LDV D, imm <=> LDV D, imm, 0. Is that possible?

[francisrstokes]

3rd argument can definitely work. While I agree the names are not the best, I'd rather take the path of least resistance when it comes to changes.

[francisrstokes]

Merged proposal to master