Page 2 of 2
Re: 32-bit Forth on the 65c816
Posted: Sat Dec 06, 2014 8:44 pm
by Martin_H
Interesting. Given that memory is plentiful on the '816 wasting a byte for each stored address seems acceptable to avoid that penalty.
Re: 32-bit Forth on the 65c816
Posted: Sun Dec 07, 2014 6:47 am
by barrym95838
Oops -- thanks, Mike. You've reminded me to mention that my "times 2" and "times 4" comments apply when the underlying machine addresses bytes -- unlike yours, obviously! And of course byte addressing, though sometimes handy, is hardly a necessity.
Since it does nothing (multiplies "times 1"), your code for
cells has only one optimization possible. When
cells appears in the source code have it defined to do nothing then, not at run time. IOW don't even compile a jump to NEXT.
J
I don't know this for sure, but doesn't CELLS have to be present in some form or other to be considered "ANS compliant"? Or does that only apply to the source code of a compliant program, and not the actual compiler output? (Still learning ...)
Maybe I could try this instead?
Code: Select all
; 1035 ;--------------------------------------------------------- CELLS
00000318:00000313; 1036 NOT_IMM 'CELLS'
00000319:0543454c; 1036
0000031a:4c530000; 1036
; 1037 _cells: ; ( n -- n' ) Cells->address units
0000031b:00000053; 1038 .dw donext_
I'm not sure if that's kosher or not (comments welcome), but I think that's about as far as I could go, at least in ITC. With no actual unique code field, it might make de-compiling or tracing a bit confusing at times, no?
Mike
Re: 32-bit Forth on the 65c816
Posted: Sun Dec 07, 2014 7:45 am
by GARTHWILSON
Do this:
: CELLS ; IMMEDIATE
Re: 32-bit Forth on the 65c816
Posted: Sun Dec 07, 2014 8:23 am
by BigDumbDinosaur
Interesting. Given that memory is plentiful on the '816 wasting a byte for each stored address seems acceptable to avoid that penalty.
It's the age-old tradeoff between performance and resource conservation.