Lisp and VLIW (was Re: Genera)
Sun, 5 Apr 1998 07:55 -0400
Date: Fri, 3 Apr 1998 10:22 EST
From: eric dahlman <firstname.lastname@example.org>
On Fri, 3 Apr 1998 email@example.com wrote:
> Most importantly, it carries the 8-bits of tag through the entire datapath and
> memory interface. The microengine can do tag comparison and dispatch in parallel
> with an operation, so for example an add instruction can assume that the operands
> are both fixnums and start doing the addition at the same time that the tag
> comparison hardware is comparing the tags. If there is a mismatch, that microcycle
> causes the result not to be stored and a trap to be taken.
Here is a question that I have been kicking around for a little while
about this type of thing. How well would lisp compile to a VLIW
architecture with predicated execution?
I'm not sure what you are asking about. I understand the VLIW part, not the
predicated execution part.
The issues of tag comparisons and
the such being performed in parallel with the operations seem to be a
gimmy source of instruction level parallelism which would be easy to take
advantage of on such a processor. Could it be that the next generation of
general purpose processors could be a real win for lisp? Has anyone
looked into this issue?
The reason, at least in my mind, for having special hardware for the tag comparisons
is that they are very stylized and instead of taking up hardware that could be used for
another higher-level operation, it is more efficient to only consume hardware resources
commensurate to the task.
That being said, it is clear that the VLM emulator gets back at least some of the
performance lost to emulation by having a fairly high proportion of dual-issue instructions
in the hand-crafter instruction dispatch loop. As Tucker Withington said, when
the VLM was designed typical compilers wouldn't necessarily do as well.
So, using instruction level parallelism in the hardware can get some of the same effect as
having separate hardware.