home .. forth .. colorforth mail list archive ..

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


> 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.
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.

>
> Howerd
> 
> 
> -----Original Message-----
> From: Chuck Moore [mailto:chipchuck@xxxxxxxxxxxxxx]
> Sent: 03 March 2004 06:21
> To: colorforth@xxxxxxxxxxxxxxxxxx
> Subject: Re: [colorforth] Low res or low color ColorForth
> 
> 
> Regarding Howerd's comment about "name-space pollution":
> 
> It is an historical accident that the editor is built into 
> the kernel. The
> colorForth colorForth will have it as a seperate application. 
> Ie., typing
> 123 edit  will compile the editor, overlaying the current 
> application. Thus
> any nice words it defines will be distinct from any in applications.
> 
> This has no time penalty, since compile is instantaneous. And 
> presumably
> you're editing the application (or some application) prior to 
> re-compiling
> it. So overlaying the application has no penalty.
> 
> Possibly, simply listing code or other text might remain in 
> the kernel,
> since that might be part of an application (browser).
> 
> 

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