Re: Are transpiling techniques different than compiling techniques?

In this interested thread, Detlef wrote:
> In contrast to a compiler, which has to be fast because it is used over
> and over again in the development of software, the speed of the
> transpiler does not matter: ideally, it only has to be used once to do
> its job.


Sometimes, this is true, sometimes not.


Twice in my career I worked on projects which developed a transpiler.


In the first case, it was true.


My mentor on that project developed a Jovial to PL/I transpiler using PL/I's
macro facility. We only used it to bootstrap the "real" Jovial compiler
to Multics, which was also only a bootstrap to get the Interdata 8/32
Jovial compiler to work. And, the Jovial to PL/I transpiler didn't have to
be real accurate nor fast nor deal with the entire language, just good
enough to get the compiler bootstrapped We may have done the
bootstrap several dozen times (but probably not several hundred)
during the development, but once the Multics Jovial compiler was
working, we never did it again. It was a throw away transpiler.


In the second case, it was not.


At Intel I was part of a CAD team for chip design tools. The tool we
built was called "VMOD" (I don't remember what that stood for). Anyway,
it had one part that allowed designers to draw gates and wire graphically.
That was the initial impetus to the project. However, it was known that
there were places where the design would be better expressed in Verilog
and we allowed the user to drop "combo" boxes (short for combinatorial
logic boxes) that looked vaguely like "chips" (i.e. they were rectangular)
and had "pins" around the edges for connecting to graphical wires.
But in those combo boxes you could use a text editor to input Verilog code,
which could refer to the pins to communicate with the graphical model.


Anyway, I did the Verilog compiler (and also the "compiler" for the graphical
gates--they were actually the same compiler and used the same IR).
But, the technology for both was transpilation. For simulation of the chip,
we transpiled to C++ code and used Visual C++ as our "backend". Our
runtime library was also written in C++. So, we got out a C++ version
of the "chip" that did a cycle accurate model of what the real chip would
do and it hooked back to the graphic model for certain aspects of debugging,
but it also generated log files and allowed debugging of the C++ code.


However, for that code, we didn't just translate once. Since the design
work was on-going and simulating the design so that the developers
could get the chip(s) right (it was used to design about a dozen or two
chips over its useful life) meant it needed to run at something approximating
C speed, which we managed to do and it was thus about 1000x of the
performance of the previous simulators that Intel had been using. In fact,
it was fast enough that teams had us do a pure Verilog version (no graphic
support) for teams that were coding in Verilog and didn't buy into the
development model that the tool was designed to promote. So, it became
a Verilog to C++ transpiler.


Of course, being for chip design, the other important aspect was synthesizing
real gates. For synthesis, we transpiled the graphic model into Verilog
and that included transpiling the Verilog combo box code into Verilog,
Now, that was mostly an identity transform except for hooking up the pins,
dealing with name collisions (e.g. renaming multiple copies of the same
box to unique names) and a few clock related portions. When it was
acting as a Verilog compiler, only the name collision and clock related
portions were relevant as there were no graphic gates and no pins.


And, by the way, there was no big secret to achieving approximate C speed.
We got it because we let Visual Studio do all the heavy lifting of optimization
and code generation. There was no way, I was going to compete with
them on that aspect and no need to. Thus, transpiling gave us a reasonably
good compiler for a fraction of the effort.


And the main thing we had to do was deal with the fact that in Verilog
each "bit" has 4 states 0,1, x and z. And the x and z states of a bit
are used in stylized ways (x means invalid and z means don't care).
So, we did a small amount of analysis to detect if the gates and wires
under consideration could have x or z values and if so, used the more
complex logic that got those values correct (and mapped each bit to a
2 bit pair, so that we had 4 states to use and we did it FORTRAN
"column major" style, so that the bits for 0,1 were in one contiguous
array for the width of the wire/bus they were representing and the
bits indicating that 0,1 was really x, z were in a parallel array and
a quick check of the 2nd array for all 0s allowed us often to not deal
with it at all for some wire/bus. And, if we statically determined
that none of the bits on that bus would ever be x or z, we didn't need
that 2nd array at all. So, things like adders could then use the
normal simple C/C++ logic for addition and not have to do a bit-by-bit
version of it.


We also had special code for clocks, because they couldn't be x or z, but most
flip-flops are edge triggered, so you want to distinguish rising edge from high
(or low) and the same for falling edge. And all the gates were partitioned into
what edge or level they were sensitive to and we only ran the code when the
relevant clock was in that state.
--
******************************************************************************
Chris Clark email: christopher.f.clark@compiler-resources.com
Compiler Resources, Inc. Web Site: http://world.std.com/~compres
23 Bailey Rd voice: (508) 435-5016
Berlin, MA 01503 USA twitter: @intel_chris
------------------------------------------------------------------------------

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