Re: 32 bit FORTH ??? Different tack!

Charles Davis <cad@xxxxxxxxxxxx> wrote:

Cross Platform tools ARE quite useful!!! No argument about that. But
I'm trying to look at things from a very 'Minimalist' point of view.
Things like Cross Compilers are NOT cheap. Free or shareware software
is quite often only worth as much as you have paid for it.

If you're interested in building your own system that you hope will be
relatively portable, it might not be much harder to build your own
cross-compiler too.

You want something that you can metacompile easily, right? So you want
it mostly written in Forth, with a minimum of assembly-language or C
routines to implement the rest. Once you have your little microkernel
that has the words you need to do simple arithmetic and compile words
into the dictionary, then you can compile everything else as Forth
words.

Well, is it harder to build your microkernel on a different Forth system
and download it to the system you want? To do that, you need an
assembler (or C compiler) to create (some of) the primitive words, and
you need to put them together into an image in memory or on disk. And
you need an assembly-or-C routine that you can put onto the new system
that can download the microkernel and get it running. (You might want to
be able to do that a word at a time, and have a way to execute those
words so you can test them on the new system. Once you have a
communication channel to see what's in memory locations and what's on
the stack, you can test things!)

So the difference between a garden-variety metacompiler and a
cross-compiler is mostly that you use a different assembler (or
different target for your C compiler), and you do a very little bit of
extra work to communicate with the new system. As somebody else already
pointed out, if you use an assembler written in Forth then you can
probably port it to your new system with no changes.

So you don't need an expensive cross-compiler. It's only a little work
on top of what you're already doing.

If you're interested in that sort of thing I"d tentatively recommend you
might look at Pygmy Forth. It's written for MS-DOS and its complete
source including x86 assembler and text editor takes about 1600
64-character lines. It was designed to be simple to metacompile. There
might be more recent systems that are as easy or easier to metacompile,
but that one was particularly clear for me and I haven't looked at the
problem since. Maybe someone else will recommend a simpler one for you.

If you wanted to port Pygmy to a different processor, you'd start out
by building or acquiring an assembler written in Forth for that
processor, and then you'd rewrite the assembler routines with the other
assembler. (Pygmy uses a lot of assembly routines, unfortunately, for
speed. Pygmy is very idiosyncratic in other ways, you don't want to use
it for your task, just study how it does things.) You'd find a way to
write the system calls. Things like (KEY and (EMIT. And you'd find a way
to download code to the new system, and to start the interpreter. Once
you had that working you could test your code one routine at a time.

This has got to be easier than building everything from scratch on a
brand new system. You can do most of the work using a functioning Forth
on a known machine that works. And once you have a communication channel
that lets you send and recieve characters to the new system, you can
test things even before the rest of the I/O works.

Forth is easy to use. So it's easier when you can use Forth for as much
of the work as possible. It's easier to use a working Forth on a working
system to bring up a new Forth. The time before you get the Forth
actually working on your new system will be a lot harder than the rest,
so minimise that by using an existing Forth to help you with it.
.

Relevant Pages

  • Re: ///Re: NASM problem
    ... in the RosAsm stantard macros are what I would call real significant and very useful. ... arithmetic at compile time isn't important. ... Seeing the ease of using Herberts dissembler, and how easy it was to compile a com.file with it, I have no doubt he could create just as good an assembler as RosAsm, if he only could see what it would mean. ... these small little details you give up the power of assembly over HLLs. ...
    (alt.lang.asm)
  • Re: from elsewhere, an assembler
    ... note that often duplicating opcodes with different names leads to inflation ... my current assembler can't figure it out). ... Compile in memory? ... moved to listing files, but at present this is not needed (could make sense, ...
    (alt.lang.asm)
  • Re: HLA question
    ... HLA is an x86 assembler. ... interpreter NEXT. ... The quantity of stack items ... Forth's dictionary, ability to compile words, Forth's inner and outer ...
    (alt.lang.asm)
  • Need help here.
    ... Iam trying to install hla and masm32 as given in Randall Hyde's book ... 'art of assembly windows version' but i cant get it right. ... HLA (High Level Assembler - FASM back end, ... -sm Compile to MASM source files only. ...
    (comp.lang.asm.x86)
  • Re: cursor hiding
    ... My interpretation is G.L. lend it to me by offering ... Netherlands server of Coos Haak or DXForth on the Taygeta server. ... decided not to ansify Pygmy that means more or minor adapting ... Other Forth assembler give the result in AX back to the stack. ...
    (comp.lang.forth)