Re: Is This a Dumb Idea? paralellizing byte codes

On Saturday, October 22, 2022 at 11:51:31 AM UTC-7, nob...@gmail.com wrote:
> Modern CPUs employ all kinds of clever techniques to improve
> instruction level parallelism (ILP). I was wondering if it
> makes sense to try to employ similar techniques in the
> virtual machines used to execute byte code produced by language
> compilers.


Seems to me it is not that parallelizing byte codes that is
a dumb idea, but byte codes themselves are.


This was known when Alpha replaced VAX. Work on making faster VAX
systems was stuck with the byte oriented instruction stream which was
impossible to pipeline.


Not so many years after IBM S/360 was the first "computer
architecture", DEC wanted VAX to be an architecture with a wide range
of implementations, and do last for many years. But VAX didn't last so
long, and descendants of S/360, now z/Architecture, are still around.


S/360 instructions are in units of 16 bits, always aligned, and you
can tell from the first byte how long the instruction is. That allows
the processor to quickly parse instructions and pass them to
reservation stations (in the case of the 360/91).


But VAX instructions have to be parsed byte by byte, until the
hardware finds how long the instruction is.


So it seems that the real answer is to devise a word oriented, or in
other words RISC, virtual machine. (Actual RISC hardware might not be
a good choice.)




I have in the past, maybe here, wondered about the ability to improve
a RISC processor. As one example, many include a branch delay slot,
which depends somewhat on the processor pipeline.


It seems that one fix would be for compilers to write out not the
actual instructions, but slightly earlier in the code generator.


Then a processor specific program would, fairly quickly, convert that
to actual instructions. That could be done at program installation
time, or at program load time, as needed.


If a new processor came along that, for example, needed two branch
delay slots, it would generate them.

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