[retroforth] Re: RetroForth 7.6 Development
- From: Charles Childers <charles.childers@xxxxxxxxx>
- To: retroforth@xxxxxxxxxxxxx
- Date: Fri, 26 Nov 2004 15:36:20 -0500
> I was surprised to find them in the kernel, I have to admit ...
> Maybe they should go to a optional "formatting" package.
Sounds good; they're now marked for removal.
> I find them quite convenient to have ... as a last resort. I've not
> done enough programming in rf to claim that they are indispensible,
> though.
That's two people (ron on the forum uses them too), so they'll likely
be left in.
> zt-make does four things
> - change here
> - copy the bytes
> - terminate the string
> - align here
It also leaves the start/count of the string on the stack. So I redefined it as:
: zt-make dup >r here swap cmove here r> dup allot 0 1, 1+ ;
> Why does the original zt-make allocate cells instead of bytes?
No idea. cmbrannon wrote the original; I didn't ask questions because
it worked, even if it was rather complex.
> : $, | addr n --
> s0 @ 2dup | -- addr n s0 n s0
> m: literal m: literal | -- addr n s0
> 2dup + s0 ! | -- addr n s0
> swap cmove | --
> ;
That works for me :-)
>> 9) until
>
> I've no idea how optimize this, but how about moving all those
> hand-compiled words into the assembler part of the sources?
> They are no real "high level" implementations anyways.
I know, but there are good reasons for the macros being in Forth: they
are inlined. So the definition of >r would be:
: >r $ad50 2, ; | forth
mcode '>r', to_r ; Assembly
upsh $ad50 ;
call comma2 ;
next ;
I actually follow the Forth version more easily than the assembly
version. Words like dup, drop, and swap could be written in assembly
though. In this case, I prefer to keep the assembler-specific code to
a (relative) minimum. Nearly all of the assembler-specific code is for
the interpreter loop and the (barebones) compiler. It's proven easier
for me to maintain since I moved things out of actual assembly. (And
the binary size has gotton smaller in many cases)
> carefully :-)
:-)
>> 11) r
>> This would be like R@ in most forths, and could be very useful in
>> larger programs. I dislike the R@ name because it implies a fetch from
>> TOR (top of return stack), which is _not_ what it does.
>
> then what would it do in retroforth?
r@ would operate like @, except taking the address to fetch from the
return stack as opposed to the data stack:
variable apple
100 apple !
." apple =" r@ .
apple= 100
apple .
12345678
r .
12345678
--
Charles
Other related posts:
