types and operators

[Captain Napalm]

A long long time ago on a network far far away, Nathan Hawkins thus said:
> 
> On Thu, 25 Apr 1996, Eric W. Biederman wrote:
> 
> >       C. strings
> > 	 I favour using counted strings, and providing a good set of 
> >    operators to work on them. We will need to mark strings so that the 
> >    garbage collector knows to leave them alone.
> > 
> > I'm not sure why the gabage collector needs to leave these allone.
> > Except that it needn't look for pointers in them.  But certainly if
> > it can be proved that the string can't be used the GC should reclaim it?
> 
> I'm sorry, what I meant was that the GC shouldn't bother search strings 
> for pointers. Therefore, strings must be marked so the GC knows what they 
> are. QED.
> 
  If you have to mark some types (even one) you might as well go all the way
and type everything.  It makes the implementation a bit easier as well as
more orthogonal (which I like - the VAX Assembly language perhaps being the
MOST orthogonal instruction set ever 8-)

> > I have figured out how to do type-safe operators (compile-time
> > type-safe) and identification of all pointers at run-time with no run
> > time cost.  What it does require though is a restriction on how words
> > can manipulate the data stack.   That is words must have a fixed
> > number of arguments and a fixed number of results. 
> 
> This restriction is would get obnoxious in almost no time. We're talking 
> about writing a very extensible language which can be expanded to handle 
> doing a lot of things dynamically. In your design, I couldn't even write 
> a function like printf! Not to mention breaking the separation between 
> the data and return stack. I'd rather stay closer to Forth.
> 
  See my previous message.  And don't be afraid of moving further from the
"Forth" ideal.  Use what's good, throw away what can't be used.

> Well, in Forth, we don't use local variables, anyway. 

  <Tonto> What's this "we" business, Kimosabe? </Tonto>

  ANS Forth does have local variables.  They're not used much, but they are
there.  And for certain operations, they are nice to have (okay, draw a box
in Forth, given the primitive LINE ( x1 y1 x2 y2 -- )).

> I think I'd rather put up with type munging. :( :( :(  You see, I'd like 
> to remain as close to Forth in design as is possible, but with the 
> needed extentions. (As well as dumping some minor stupidity in the Forth 
> I/O words.) But I do want it be close enough that most ANS Forth would 
> run, provided it obeys the rules of ANS Forth.
> 
  I wouldn't be that concerned with ANS compatability.  You can always add
an ANS layer (provided your base has a good foundation).

> In general, I'd like to stay away from stack frames. I'd prefer to not 
> have those at all, or let the hll use them if it wants. But not in the 
> lll, or its calling convention. Those are just my preferences, though. 
> We'll have to see what other people think.
> 
  From _Computer Programming and Architecture: The VAX-11_ by Henry Levy and
Richard Eckhouse, Jr.:

	Argument Lists and Call Instructions

	  For the VAX-11, arguments are transmitted to a called procedure
	in an argument list.  A VAX-11 argument list is an array of
	longwords [each longword is 32 bits -spc]in which the first longword
	contains a count (in the first byte) of the number of arguments to
	follow....

	  Each entry in the list can be a value or an address.... The 
	argument list can be allocated in static memory or can be pushed on
	the stack prior to the call.  Consequently, there are two forms of
	the Call instruction.

	  The General form, CALLG, takes as operands the address of an
	argument list anywhere in memory and the address of the procedure
	to call.  For example, suppose we wish to invoke routine MYPROC
	and pass it two arguments whose values are 600 and 84.  The
	following code shows the allocation of the argument list and the
	Call instruction:

			<data section>
		ARGLST:	.LONG	2	; argument count
			.LONG	600	; first argument
			.LONG	84	; second argument
			 .
			 .
			 .
		BEGIN:	<code section>
			 .
			 .
			CALLG	ARGLST,MYPROC	; call procedure MYPROC with
			 .			; argument list ARGLST
			 .
			 .

	  If a second call to MYPROC is needed with different values for the
	arguments, the main procedure could use a different argument list or
	dynamically move the values into the list starting at label
	ARGLST.  [Although if MYPROC changes the values in ARGLST, then 
	the change may be global and not what the programmer intended.  Just
	pointing out possible bad side effect. -spc]

	  The second form of the call instruction is the Stack form, CALLS,
	in which the argument list is pushed onto the stack.  The following
	example shows the invocation of MYPROC using the CALLS instruction:

			 .
			 .
			 .
			PUSHL	#64		; push second argument
			PUSHL	#600		; push first argument
			CALLS	#2,MYPROC	; call procedure MYPROC
			 .
			 .
			 .

	[paragraphs about the tradeoffs between the two methods deleted
	-spc]  ... Still more important, the stack form of the call allows
	for nested routine invocations and permits recursion and re-
	entrancy .... [but the caller routine can simply push the arguments
	it received onto the stack and call itself with CALLS, or allocate
	memory and store the arguments into there, and call itself with
	CALLG, reguardless of how it was originally called -spc]

  Don't discount the idea of stack frames either (and in the case of the
VAX, the result of CALLS/CALLG is that R12 (AP register) points to the
argument list, with the first element being the number of arguments).

  -spc (Just tossing ideas out ... )