The current implementation maps the 2 letter lower case mnemonics into a byte and packs 4 together to build an instruction. Would be handy to allow 2 character upper hex numbers into the byte. This will allow for special vm opcodes to be activated in a consistent manner. Since its using upper-case and numbers it should not interfere with the current and future control of the core vm instructions.
I'm assuming this is in relation to the runtime assembler?
Assuming that this is for the runtime assembler, try this: http://forth.works/share/2096293743bc1f990df862786d30e8f2
This will replace
i
with a new one that supports hex numbers (in uppercase) if the decode of the two letter name fails. Since it replacesi
, words using that (such as the\
prefix) will then use this instead.
Thanks, that's what I was looking for. Its going to allow easier access to some VM specific op codes.
One question; could you provide some comments on the last 2 lines? Especially what #1793 is doing there...
#1793 &i store &assemble &i n:inc store
Here's a copy with comments: http://forth.works/share/8117e259d54304b7fd59ec8456ebb824
#1793 is the assembled instruction sequence corresponding to liju.... (push address to the stack snd jump to it). In this case, I replace the first two cells of the original definition for
i
with the instruction and the address of the replacement definition.
Thanks for the additional comments. Seasons greetings BTW.
Any thoughts on why :quad is significantly more complex than :tri to implement?
Also; do you think this beefed up version is worthy of inclusion in 2021.1?
PS. Is the new code missing a --reveal-- or I am missing something about how {{ }} works?
No, the
---reveal---
isn't missing.
{{
begins a private namespace
---reveal---
switches to the public one
}}
hides the headers in the private namespace.Without a
---reveal---
, all of the headers are considered private, and are hidden when}}
runs.I don't use this aspect often, but in a case like this, it can be useful.
I've committed this as an example.