types and operators

[Nathan Hawkins]

On Sat, 27 Apr 1996, Captain Napalm wrote:

> > On Tue, 23 Apr 1996, Eric W. Biederman wrote:
> > > Now all we have to do is figure out is what kinds of data types and
> > > which opeations on them, our lll will support.
> > 
>   [ FYI - major editing ]
> 
> > I. Data types we will _need_
> >    A. integers
> >    B. pointers
> 
>   It seems you want to be able to distinguish between integers and pointers
> by looking at the (for lack of a better term) object rather than carry type
> information around.  I feel that's not the way to go and would rather carry
> around type information (external to the object, in the case of integral
> (internal) types).  
> 
>   For instance, given the following:
> 
> 	integer     color  = 0x00083414;
> 	integer ptr pcolor = &color;	// given the memory map, this is
> 					// at address 0x00092D08
>  (in some pseudo-Cish language)
> 
>   By just looking at the objects, how can you determine what they are?

You'd have to use some bit pattern, and use less than 32-bit integers 
with a 32-bit word. :-( Btw, /I/ don't want to do this, but it seems to 
be necessary to support this GC thingy. Either that or stack frames, and 
I'm _really_ opposed to that idea.

> >    C. strings
> > II. Optional types
> >     A. buffers
> >     B. floating-point
> >        Floats would be a mess to do, especially when it comes to 
> > distinguishing them from integers, pointers and strings. This can 
> > probably be added later.
> > 
>   If you mean by looking at the object, yes, it will be difficult, as will
> be distinguishing between integers and pointers (see above).

More of a nuisense, since floats are of obscure sizes. 10-byte for 
instance. In fact, of the types I mention here, floats would be the 
biggest headache, in general, especially since cooperative tasking would 
lose, since the x86 would make you insert a FWAIT before switching 
contexts. 8-( (I think so, anyway.)

> >     C. double-length integers
> > 
>   And how do you determine an integer from a double integer?

Why should I? Would this be important? It should be possible to treat any 
two integers as a double int and vice versa. This shouldn't give the GC 
any problems, and would be very handy, although there would be 
portability issues.

> > There will need to be some thought put into stack operations. I was 
> > planning on keeping the standard Forth ones. Any comments on this?
> > 
>   One thing I dislike about Forth (and this comes from years of Assembly
> experience) is the amount of "stack noise" that comes about from
> manipulating the stack.  I personally like the ability to address the
> "stack" as an array, but at the same time, I know this violates the purity
> of Forth (or of stack based languages in general) and may be difficult to do
> depending upon the implimentation.
>
>   For lack of any better advice, okay.

With TOS in a register this isn't that bad. Besides, I'd keep PICK if 
allowed to. :-) And you can do some neat things with 2ROT and 2OVER.
And yes, I was bothered by this at first, too. But compared to C, even 
with a decent optimizer, Forth doesn't make that bad of mess of things.

> > Also, I'd like to have a some ideas about how to do pointer/integer 
> > distinction with a minimal instruction count for operators. Since + - * / 
> > etc. will all have to convert LLL integer --> machine integer 
> > conversion and back, I'd like it to be kept to something we can do with a 
> > minimal instruction count.
> > 
>   Separate type information.  This doesn't have to be kept around all the
> time (like some Forth systems strip the headers of each word once the
> application is written - not all words are meant to be used at the highest
> level).  Once the "program" is running, then type information (and type
> checking) can be removed.

But that does require that when a number is written into memory (as 
opposed to on the stack) that it be munged again. I was thinking of using 
the low two bits of a dword, and using SHR and SHL to convert integers, and 
using AND and OR for pointers. This would allow a simple TEST to 
determine the type, and possibly we could take advantage of hardware 
alignment checking to help debug things.

> > Finally, a question of operator behaviour: should operators be type-safe, 
> > or should they just produce undefined results? For instance: what happens 
> > when you add a pointer to an integer with the integer addition operator?
> > Also, if operators are type-safe, what should they do when given the 
> > wrong parameters? (Exception-handling?)
> > 
>   During development, they should be type-safe and if an illegal type is
> specified, an exception should be thrown (or dumped into a debugger). 
> Dumping core is NOT an option 8-)
> 
>   During regular use (assuming the program has been fully debugged) then
> there should not be any type mismatches, but if something does happen, the
> easiest (and fastest) would be for undefined behavior/results.  Buyer
> beware and all that.

This would require having separate versions of + & co. for debugging and 
normal run-time. But that's possible in Forth. :-)

Funny, I thought the whole idea behind Tunes was to cheat the whole 
caveat emptor problem...

*utsl*