some nibz decoding ?

The following is much easier for me to understand, with my ETH-oberon system, where I colour/font the 'conceptual groups' of text, better than you can mark a paper-text with multi-coloured pens.

Since I've spent the labour [now for the 2nd time to recheck] you are free to benefit too. PS. I've perhaps mis-quoted what Jacko wrote with what I've deduced. This is 'hand made', not just generated by Micro$loth !

> Let's try to work backwards:- >> (R)->P should move #$222 to address $666 >> ==> P == address $666 >> and >> R pointed to mem-containing #$222 >> So, how did $lit , $222 [ push $222] get >> $222 into mem pointed to by R ?

---------- Jacko explained:-

RI FI SO RO BA where SO RO commutes to RO SO as a duplicate > expression for same function.

A->(S);Q->(R) commutes to Q->(R); A->(S) == order is irrelevant ==> RI FI RO SO BA == (R)->Q; (Q)->A; Q->(R); A->(S); (R)->P == (R)->Q; (Q)->A;A->(S),Q->(R),(R)->P

(R)->Q,(Q)->A,A->(S),Q->(R),(R)->P > get return address and get indirect next address following return > address, and save this on stack,

== (R)->Q,(Q)->A,A->(S) ? doesnext address following return address contain #$222, perhaps code format is 2 words: lit, #$222 ? If so, lit must push the next-word. I.e. starting from: lit knows its own adr., and S knows TOS, and lit's adr. gives the subroutine's return.

and put incremented return address > back on return stack

Q->(R)

BTW I disagree with your wording: 'put back'; which implies that it 'move away'. AFAIK the data doesn't 'move'. It copies ? [ IMO intel/Motorola used 'move', because the 'other' had already 'copyrighted' 'load'] So the apparent reason why you'd copy from Q to R, when you had previously copied from R to Q, would be that the data had been 'stepped', so that an updated data replaces the original data. The mental acrobatics required for a newby without a simulator, is considerable ?

and get return address (modified by +1) into > program counter

(R)->P == return

to execute a return to the address following the > literal value.

---------- Wow ! Very interesting. I supose when you've been doing it for a few hundred hours, it's natural, but I think the 'primitive instruction routeing' to acheive the subroutine goal, would make a nice exercise for an AI utility. It maps directly to various AI techniques.

---------- Rather than search for Rick's verbatum crit., I'll try to paraphrase my understanding of it, and add my own [perhaps wrong] understanding:

nibz instruction's are inefficient because

you have to have 20-bit wide to get 64K adr-space. AdrSpace = 2^ (wordWidth - 4). And that's 64K 20bit-words.

and then since there are only 16 primitives, these use only 4 of the 16 bits.

I wonder what the typical ratio is of primitives to subroutines + literals ?

The 16 primitives almost sound as if they are at a lower-level in microcoding, but apparently not ?

The common optimisation of small literals is not possible.

Well, the common inc(tos) and dec(tos) [I don't know the forth words off-hand] would be subroutines, and as Jacko writes, any literals which appear in the code more than once, are just all fetched from the same memory location, using 2 words of code. [These are memory-size 'words' NOT 'forth words'.]

And then could you optimise for space with less speed, from: [literal] [pointer to the value] = 2 words to [subroutine of literal of value] = 1 word; where, again 'the value' is in memory to be accessed in multiple sections of the code, by the same subroutine ?

-------------- Since Jacko made the common/natural mistake of 'branching off' to mention optimisation issues, while describing the basics of eg. the instruction set, IMO it's naiive to think that he hasn't already considered all the 'problems' that Rick has raised. Let's play the ball, not the player ?

Yes, this is a time-sink, but I want to go on to see if I can 'decode' the SD-driver info in the wiki.

Without deep though on it yet, the ability to have the same code for different word, memory sizes seems to have great merit - Java-ish ?

BTW, how are such fpgaS for power consumption compared to eg. an ARM ? Does anybody think that ePaper will ever be viable ?

Thanks,

== Chris Glur.

No 16 bit wide =3D 16 bit (the first 16 locations can not be used to store subrotines, as the code addresses are the basic instructions)

As programs grow the ratio of sub/lit to primitive gets larger in favour of sub/lit code.

They are simple enough to be microcode, but can be used in any code.

Some of the cpld/fpga have a very low power figure, I have no figures for the ARM, but nibz is small and hence in full ASIC would have a very low stanby current, and possibly even a lower dynamic operation current (using on chip RAM), per effective code executed. Although this depends heavily on the clock speed and ratio of static to dynamic signal lines averaged over many cycles.

FPGA versions of the ARM are available at quite a high cost and logic area.

Epaper is closest to OLED displays at present, in terms of print technology. Epapers main problem would be printing a uniform substrate layer, and developing soluable semiconductor inks which set an dry to a controlled thickness for gate oxide layers, for suitable FET/CMOS voltage.

cheers jacko