🚀 go-pugleaf

In article <2069@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes:
<> 	* data addressing.  This can either be 32-bit absolute
<> 	  or 16-bit relative.  *Pointers are 32-bits in either
<> 	  case*.
<
<This sounds more like a job for Mr. Optimiser than something the programmer
<should have to deal with.

Yes, but - the optimiser may not know the answer when it's generating
code. You see, the problems tend to be with globally allocated data,
whose address isn't known until link time. So what's an optimiser
supposed to do?

<> 	* code addressing (jsr's.)  These can either be 32-bit
<> 	  absolute or 16-bit relative.  Again, you can mix
<> 	  models.
<
<And again, this is an optimisation that should be applied to all code. The
<UNIX *assembler* on the PDP-11 did this: you just specified that you were
<branching, and it'd generate either the short branch or the long branch
<depending on how far away the destination was. Surely a compiler can do this
<within a routine and for calls to static globals.

Note: the PDP-11 "as" handled _branches_, not subroutine jumps. So it
knew both the source & destination of the branch. If your 68K compiler
doesn't handle internal branches as described above, get a smarter
compiler!

On the other hand, subroutine jumps could be to routines that you
don't have an address for yet (they may not even have been written yet
:-). So once again, the optimiser is missing some important data.

<> 	* int size.  Both Manx and Lattice allow 16 and 32-bit
<> 	  ints.
<
<	4) Manx did a half-assed implementation of the X3J11 draft: no
<	   function prototyping. When they wake up and put it in then the
<	   whole thing will become a non-issue.

Lattice did a quarter-assed job. They got function prototypes into
4.0. They also got hooks in to generate calls to libraries inline,
instead of through a stub, and tied the latter to the former in their
distributed files. If you ask for prototypes, you get the inline code.
They could be seperated, but who would not either one of them?

It's not clear that the "models" on the 68000 should be called
"models". After all, you can mix code from between all the models
without too much trouble. This isn't really true on the intel
processors.

	<mike

--
The road is full of dangerous curves			Mike Meyer
And we don't want to go too fast			mwm@berkeley.edu
We may not make it first				ucbvax!mwm
But I know we're going to make it last.			mwm@ucbjade.BITNET