Re: Compile HLL to microcode on VLIW - possible?

"Alaric B. Williams" <alaric@abwillms.demon.co.uk>
3 May 1996 23:41:43 -0400

          From comp.compilers

Related articles
[10 earlier articles]
Re: Compile HLL to microcode on VLIW - possible? doconnor@sedona.intel.com (1996-04-20)
Re: Compile HLL to microcode on VLIW - possible? WStreett@shell.monmouth.com (1996-04-29)
Re: Compile HLL to microcode on VLIW - possible? alaric@abwillms.demon.co.uk (Alaric B. Williams) (1996-04-29)
Re: Compile HLL to microcode on VLIW - possible? bill@amber.ssd.hcsc.com (1996-04-30)
Re: Compile HLL to microcode on VLIW - possible? ok@cs.rmit.edu.au (1996-05-01)
Re: Compile HLL to microcode on VLIW - possible? Arthur.Chance@Smallworld.co.uk (1996-05-02)
Re: Compile HLL to microcode on VLIW - possible? alaric@abwillms.demon.co.uk (Alaric B. Williams) (1996-05-03)
Re: Compile HLL to microcode on VLIW - possible? andyw@ibeam.jf.intel.com (Andrew T. Wilson) (1996-05-06)
Re: Compile HLL to microcode on VLIW - possible? Don_Lewine@dg-webo.webo.dg.com (1996-05-10)
| List of all articles for this month |

From: "Alaric B. Williams" <alaric@abwillms.demon.co.uk>
Newsgroups: comp.compilers,comp.arch
Date: 3 May 1996 23:41:43 -0400
Organization: Compilers Central
References: 96-04-059 96-04-165
Keywords: optimize, architecture

> [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]


--


Post a followup to this message

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