RE: [colorforth] To kernel, or not to kernel

[Albert van der Horst <albert@xxxxxxxxxxxxxxxxxx>]

On Wed, 10 Mar 2004, =?iso-8859-1?Q?Fr=E9d=E9ric_DUBOIS?= wrote:

> > This begs the question - what should go in the kernel, and what should
> not?
> >
> > Maybe I have been going in the wrong direction when I took
> > common words out
> > of applications and moved them into the source-loaded part of
> > the kernel. An
> > example is 1@ which was used by several apps, sometimes under
> > a different
> > name.
> > My instinct was to move such words to the kernel.
> >
>
> I think it is the role of the kernel to hold the definitions common to your
> apps. Then it can harbor the utility apps you want at your fingertips, too.
>
> > There was a thread on comp.lang.forth about how much people hated the
> > snippets of hex used to define "assembler" macros. I think
> > there was an
> > assumption that all assembler macros should be collected
> > together into an
> > Assembler, not scattered amongst the code.
> >
>
> I'm interested in Albert's "postit prefix assembler". I guess that what
> people dislike is not having an assembler so each time you need a CPU
> specific instruction you have to enter again into Intel's nightmarish opcode
> encoding. OTOH a full assembler is somewhat overkill. Albert's assembler
> seems to me an interesting intermediate solution, requiring a moderate
> knowledge of Intel assembly and eventually a small quickref card.

Oops. Maybe I gave the wrong impression. The postit prefix assembler
is your typical Forth battle axe. Very powerful, in skilled hands.
Its simplicity derives partly from not hiding anything of the Intel
Pentiums ugliness. So you cannot without the original Intel
datasheets.
An example: the Pentium has in fact no instruction
    MOV   EAX, EBX
You may not know but there normal assemblers are taking a decision for
you!

In pifu you have to choose from the two equivalent instructions:
    MOV, X| F| AX'| R| BX|
("move xcell from primary register AX register BX")
    MOV, X| T| BX'| R| AX|
("move xcell to primary register BX register AX")

(There are countless LEA instructions to that same effect, but I will
leave it at this.)

> Furthermore, it might don't needs to actually assemble things into memory:
> it can just display the hex stuff that you then insert into the source.

It would become a lot more complicated if I tried that!

Currently in ciforth the assembler (with different screens
to load for 16 and 32 bits code) is about a dozen screens, including
the "defining words" part. (So not the "de luxe" version with
elaborate error checking, disassembler and ``SHOW: <opcode>'' help,
that sits in source files.) This allows to add code words, but
normally one would debug those words beforehand, using the "de
luxe" tool.

It is a full i386 assembler (all addressing modes but not all the MMX
and FP instruction enhancements.) This could be the starting point for
a tool that fits nicely into colorforth, maybe leaving some things
out, aiming for half a dozen screens.

OTOH I could imagine that the proper way for colorforth is what
I would call an eclectic assembler. This means a very limited
selection of exactly those things needed colorforth.

--

Albert van der Horst,Oranjestr 8,3511 RA UTRECHT,THE NETHERLANDS
        One man-hour to invent,
                One man-week to implement,
                        One lawyer-year to patent.
avdhorst@xxxxxxxxxxxx     http://home.hccnet.nl/a.w.m.van.der.horst

---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com