A few things have occurred to me regarding the
WORDSIZE instruction in
wo. Namely, that changing word size in the middle of a program could be entirely unpredictable – my first thought would be to break every word out into an array before interpreting (aside from the
WORDSIZE instruction itself), but that would be impossible – the stack would necessarily have to be computed before
WORDSIZE could execute. Even before this, I was wondering if I should really prioritize it so low in the instruction set, or if it just turns into an abuse of a reduced instruction set claim.
I’ve been thinking a lot about registers as well. My plan is that, much like instructions, no registers will be reserved. A system register will hold word size, and will be user modifiable, but this will not be an encouraged behavior. I haven’t really thought through the possibilities yet, whether or not any of them will actually be interesting, but there is some hackish possibility of messing with the word size register and
GOTOing the middle of an otherwise specified word.
I have a post drafted that explains how a few other potential details will be implemented – like doubles, and a ‘magic number’ concept. Storing and retrieving registers is increasing in priority in the instruction set, and I think the ‘magic number’ will allow that to be one instruction. Inputting strings was another reason to allow changing word size, but I think creative use of double- or (more)-length numbers, as well as a more clear delineation of what, realistically, a given word size should accomplish is the best path forward. Strings get their own (sort of, kind of, wait for further instructions…) stack which can’t be manipulated with low instructions anyway, so saying ‘string manipulation is ‘reserved’ for
wo6’ seems perfectly fine to me.