Bootstrappable language

Jim Battle frustum at pacbell.net
Wed Dec 10 23:20:34 CST 2008


bfranchuk at jetnet.ab.ca wrote:
> blstuart at bellsouth.net wrote:
>>> Any good leads as am still looking for a small boot strapable 
>>> langauge here.  Tiny C will not work
>>> as my instruction set does NOT have register to register operations. 
>>> I plan to have a wopping
>>> 48Kb system as that was BIG memory 1975 ish.
>>>     
>>
>> The two that immediately jump to mind are forth and lisp.
>>
>> BLS
>>
>>   
> Off hand I have not seen many small LISP's around other than the one
> for the PDP-1. I think there was one for the 6800 once, but LISP tends to
> need lots of memory space. I could do Forth but it would be slow as I have
> no auto-incriment registers and wound need to use memory variables.   
> More like  NEXT:  ISZ  FPC; LD IX I FPC, JMP I IX+0

Ben you have said these three things in this thread:

(1) "Any good leads as am still looking for a small boot strapable langauge here."

(2) "Tiny C will not work as my instruction set does NOT have register to register 
operations."

(3) "I could do Forth but it would be slow as I have no auto-incriment registers and wound 
need to use memory variables."

What is your goal?  If you don't care to have any existing code base to draw upon, then 
you should be able to make up a language that *does* fit your weird-ass architecture, 
whatever it is.  If you do hope to have some semi-standard HLL language so you can then 
run existing code, it sounds like you are off to a bad start if you can target neither a 
pared down C nor Forth.

I don't see why the lack of register to register ops would prevent implementing a tiny C. 
  There is nothing in the language that would demand it.

Some of the Tiny-BASICs published in Dr. Dobbs early on were two level interpreters, kind 
of a specialized byte code.  They would define some artificial machine code that was easy 
to implement on an 8b micro, and then wrote the Tiny BASIC in the artificial machine code. 
  It made the interpreter slower, but it saved bytes and made it possible to move the tiny 
basic to another uP by rewriting just the artificial machine code interpreter.  The Apple 
II ROMs had the SWEET-16 interpreter built in.


More information about the cctech mailing list