Goals and...
		results


demonstrate viability of a 3-stack arch.  
	It works. Pretty well. The pointer stack is more like the Forth
	data stack than the H3sm data stack is. 

demonstrate variable precision ints.
	They work too, although literal is still a quick broken hack.

Show that a simple machine could do this
	H3sm has 100 primitives, except for syscalls, i.e. I.O. The
	primitives are bulkier than a Forth's, but they are fighting
	arbitrary precision integer math in C. I think it's evident that
	a H3sm would only be arithmetically larger than a Forth in silicon.

show that namespace explosion is reduced.
	There are +-100 primitives. Forth words for all possible pyte ops
	would be silly, but would be thousands of words. New definitions 
	will reflect this somewhat, e.g. you can write e.g. one integer 
	sine routine for all pyte sizes. Also, writing variable precision 
	result routines is relatively easy.
	
show that stack-dancing is reduced.
	Per stack it is, but multi-stack is tricky. The data stack only has
	5 stack ops, including bump (undrop). I don't miss PICK, ROLL, etc.
	I've had some desire for locals, but I'll get over that. 	

Show that a simple branch resolver is adequate
	Generality is easy. "goto" ( go0, go1 etc.) and "if" (yes and no)
	is known-general. When I have "see" and some fancy variants thereof 
	that I have in mind then simple may even again prove superior.

Demonstrate independance from libc in C
	done. Assuming a few syscalls. Minimally read, write and exit,
	as reflected in bye, emit and, uh, wait in Forth, readstdins
	in H3sm. Or some drivers in a bootable. I think that's the only
	parts that need to be re-written for H3sm to be bootable.

Show reasonable performance
	H3sm does "bench" about twice as fast as a null loop in Perl. Not
	bad for a demo implementation. Far from GForth, though, not to
	mention C. Note: H3sm may recurse unusually well, since it's all
	in main(). I don't have a smudge bit. Recursion is trivial.

explore features for a unix user-space TIL

	syscalls as primitives
		some need wrappers. It's a powerful thing though, clearly,
		and cheap.

	file-handling syntax in the outer interpreter   
		Not yet. See next item

	reconcile unix command syntax with Forth-like syntax
		This one is tricky.

	demo abbreviations
		They work. In definitions even. I like em. 
		' doesn't do them yet. It should.

NOT THERE YET
	
	No general string stuff yet. If you want "Hello World" use emit.
	Should be Real Soon Now(TM) 
	
	No case construct. 

	Hex only. Floats are a distant dream. (and floats are for those 
		who can't swim  :o) 

	(I think I have the requisite primitives for bases, cases and
	strings.)


SIDE-EFFECTS

The advantage of pytes doesn't show up while building the system. Setting
Size to charsize is nice, but not such a big win. Then again, I'm not
Chinese.  Hopefully pytes are more useful when H3sm can deal with the
full arbitrariness of the outside world.  Like graphics. Then an 2k-bit
XOR may be handy.

H3sm has two things that often want to be on the return stack, loop
indices and the parent context's Size. Size is usually first on and last
off in a word. That could even become semi-implicit maybe. The sTOr
doesn't have to be followed by a setSize. I need to look at nested loops
too. Apparently one wants an i and a j. 

H3sm is basically un-optimizable, as far as automatically. A
non-optimizing C compiler would be just as good for this kind of code, if
it had computed goto.

Much pontificating about C style is in the <C file. Don't declare
pointers. Use casts. I've got H3sm down to one pointer declaration. 
Unfortunately it's ip, so the un-retrofitting stopped there. (well,
argv also, but that's from the OS.)

Forth has a delightful "Oh! I'm done!" property. Stack-dancing is often a
prelude to a pleasing moment when it just falls together.  This persists
in H3sm. I've frequently been surprised at what worked the first time.
Re-factoring "interpret" and sticking TOISIV in it, for example. That one
made me feel like I had really gotten away with something. Once you
understand what you're trying to do, it goes pretty well. 

Do glance at aslist. That's a facility of gas that I think is little-known
and under-utilized. 

I haven't written /mod yet, but it seems it can complement * in such a way
that they can be combined into an any-Size equivalent of Forth's */. 

As H3sm nears fullish functionality, it's size growth is slowing down. 
Sometimes with a bit of re-factoring it gets smaller. 

H3sm needs to have a writable .text linking section. To unix, that
constitutes self-modifying code. This raises some security issues. A
buffer overflow won't be on the machine stack, it will be in the H3sm
dictionary. Well, at least the script kiddies will be writing Forth :o)

The 2-frame data stack so that a user can "undrop" without "staining"
from unknown interpreter stack effects is ugly, and worse, isn't a simple
push-pop model of a pure hardware stack. However, it's in the outer
interpreter, and could be emulated without access to a stack index
register with just pushes, pops and a global. There are several tradeoffs
in H3sm where the outer interpreter gets the raw end of the deal. The
threading scheme, for example. Chuck likes to just-in-time-compile. When I
understand that maybe some of this will change.

open works now. One can interpret a H3sm code file less than 1k in size. I
need a name for a file like that. Hmmm, a "block"?  ;o)  Syscalls that
need wrappers, i.e. that take C string arguments, should be called
something obscure like sys_open so that the wrapper can usurp the default
name. 

There's a lot more boundary conditions and ambiguities in H3sm than in
Forth. In many cases though you can avoid them if you can't abide them. 
For example, defining new words currently only works if Size = 4. I can
and should fix that, but it's quite survivable as is. Well, that's maybe a
bad example, but... 

That's the new stuff. However, when you write your own Forth, and you do
something a bit non-standard, such that you have to re-think everything,
you develop a deeper awe for what Chuck and friends have already thought
of. The interactions of a complete Forth are subtle and beautiful, and
tricky as hell. The parts are simple. When you write one you find out how
deceptive that is. The whole is not simple. It's like a great chess game,
where stupid little pieces of wood seem to become powerful magical beings.

I made up a variant of chess once I called polychess. Both players have a
piece of paper they draw thier initial position on. You can set your
pieces up anywhere on your side of the board, except you have to have 2
colors of bishop. When both players have privately completed thier setup,
the board is set up as drawn, and a coin is tossed for first move. 

Polychess, unfortunately, hasn't supplanted regular chess. It was a lot of
fun though, and very much accelerated the game. I know a couple tournament
chess players, and they both kicked the snot out of me at polychess, my
own invention, as handily as they did at regular chess. Regardless of
first move even. I invite the Forth community to do the same with H3sm. 

Rick Hohensee
Mon Feb 28 17:08:40     2000

