Re: Compile HLL to microcode on VLIW - possible?

> [I've used systems with completely customizable microcode. They ran
> as though stapled to a snail. -John]


bill@amber.ssd.hcsc.com (Bill Leonard) wrote:
>Me too! In fact, Data General had a project during the late 70s and
>early 80s to produce such a system. I was working at DG at the time
>and watched this system progress from a dream to a fiasco.
>Originally, it was to have customizable microcode that would be
>tailored to each programming language and to the kernel. Trouble was,
>every system call then resulted in two (very expensive) switches
>between microcode sets. Took 20 minutes (no kidding!) to run the
>Hello world program! Made snails look like speed demons!


But if you have seperate m-code for each session - that's bad. Just
keep the same opcode set, if switches aren't efficient, which is
likely to be the case. Have a few kernel opcodes, and a handful for
each major-paradigmy language; a VMT lookup for C, something to
traverse lists/trees for LISP and PROLOG, etc.


If it's slow switching, NO GO.


In fact, the CPU makers might just as well take a look at the software
market from time to time, look at compiled code, and find the most
common repeated sequences, ie before constant push on PCs:


MOV AX,1234
PUSH AX


and create a special opcode. Intel must have done something like this
in the given situation. Hurrah, a good word for Intel (rare these days.)


Regards,


ABW
--
Alaric B. Williams Internet : alaric@abwillms.demon.co.uk
<A HREF="http://www.hardcafe.co.uk/Alaric/">http://www.hardcafe.co.uk/Alaric/</A>
[Well, now that CPUs are faster than memory again, the wheel of reincarnation
spins back to the early 1970s. Son of VAX, anyone? -John]


--

Return to the comp.compilers page.
Search the comp.compilers archives again.