types and operators

[Eric W. Biederman]

We all seem to have some strong ideas about how this thing should
work.  What we need now is an implementation and a code base to argue
over.  At this point everthing else is pointless so I'm shutting up.

One comment about frames & GC etc.  I'm frustrated because I found a
solution to a lot of things that wouldn't inconvinience a programmer
in any other language but forth.  Arrgh, we're working in forth!

A final note on what to do if we violate type assumptions, what
happens is undefined! No, exceptions nothing.  Higher level code can
worry about that.

   >> As well as allowing garbage collection, and definite identification of
   >> things, it will also allows, some of the trickier things with lambda
   >> functions where they same their return stack.  I'm really not certain
   >> what kind of discipline is required of functions that get returned
   >> through multiple times to keep it all consistent. (We can cross that
   >> bridge later).  Also this enables all kinds of traditional
   >> optimsations that C can use, and possibly allows using a hacked
   >> version of GCC as our code generator.
   >
   > Not really, C would not be very friendly about having multiple return
   > values, especially since C on the x86 returns values in EAX. As for 
   > hacking GCC for a code generator: you're out of your mind. Have you taken
   > a close look at the source to GCC?
Yes
     It'd be better (and probably almost as
   > fast :) to write the code generator in a combination of Awk, Sed, Perl and
   > Icon, with a big shell script piping things all over the place....
   > While you're at it, you might as well build a front end for ADA as well.

The HLL comes first :)

      Yeah. C might be most useful if we can use it "as is", in an OTOP
   environment. But as we intend to do runtime code generation,
   GCC is out of question. And as utsl says, GCC isn't something you can
   extract a part from: by the time you manage to get something running,
   you could have rewritten it twice.

Actually the innards of GCC aren't all that bad.  The outards are
terrible though.  At some point we will want to create a high quality
native code generator, for the lll.  The reason I suggested messing
with GCC is that we don't seem to have any compiler experts here, and
even if it took us twice as long to clean it up, we would support
nearly a dozen platforms instead of just one, _and_ we wouldn't have
to maintain and improve the thing.  But it is a long range option, and
so should be tabled for now!


   >> Things only need to be orderly to present to the garbage collector
   >> when a function calls allocates memory from the heap or calls some
   >> function that might.  So in general at function call time.

fine GC runs only at programed points but in general you don't know
where they are so when you hand control to another routine be prepared
for it to invoke the garbage collector!

      As a side note, we still haven't decided how "return addresses"
   would be encoded. 

Encode them normally the GC won't have a problem.  Most of the time the
words will be reachable from the dictionary anyhow so this is mostly a
nonissue except when I move things.

I'm willing to writa a GC routine that will handle everyhard case
except trying to use DWIM to find the pointers.

Eric