Re: Is Assembler Language essential in compiler construction?

"Walter Banks" <walter@bytecraft.com> wrote in message
> Ralph Boland wrote:
>
>> On Feb 9, 3:34 am, marco.m.peter...@gmail.com wrote:
>> > Is Assembler Language essential in compiler construction? I've read a
>> > few e-Books on compiler construction and it always says that knowledge
>> > of assembly is essential.
>>
>> Frankly, most university first courses on compilers don't spend much
>> time on the back end of compilers; there just isn't time. And the
>> assembly languages of most modern processors are just too complex. I
>> would like to see the Java virtual machine or some other used virtual
>> machine be the target language for a first course on compilers, if
>> that is not already too much information. Students would find this
>> more interesting and useful than a faked machine language and more
>> reasonable than a real assembly language.
>
> Another approach is to teach this in two stages using a real
> processor. A few years ago (actually a lot of years ago) I used a
> real processor and created documentation that eliminated all of the
> redundant instructions.
>
> I eliminated zero page specific addressing modes. I eliminated most of
> the utility instructions like clear and complement registers. I
> eliminated test instructions. This reduced the processor complexity
> and in general it kept its functionality intact. This meant that in
> the first round it minimized the time needed to become familiar with
> the instruction set. The focus was on algorithmic optimization during
> code generation.
>
> The changes I made included creating a macro assembler for the new
> reduced instruction set.
>
> The second round could then focus on processor code generation
> optimization.


This is a very interesting approach.


I had instead ended up working the opposite direction, namely starting with
what I was familiar with (high-level stack machines), and using this as the
basis for the IR.


now, there became an issue:
nearly all of the complexity of the compiler got absorbed into this IR, and
this IR compiler still needs to be extended some with "core functionality"
in order to be able to handle more advanced cases (such as interfacing with
an object system...).


my last attempt at re-engineering everything stalled though (I tried
re-engineering everything, but it all broke and turned into a big mess...).
but, with the current working IR compiler, it is a bit awkward and
inflexible.


to a large degree, it can only really be extended by adding new low-level
code generation (then dealing with x86 vs x86-64, ...), where I am now
thinking it may need to be able to generate new pieces of code at its own
level of abstraction (requiring reworking more of the internals, ...).




so, I am left with the thinking, in an "ideal" design there may need to be 2
levels of IR:
a high-level IR, which takes a fairly high-level and abstract and
"cannonical" representation (ideally, at a similar level of abstraction to
.NET/CIL);
a low-level IR, which glosses over the native code generation somewhat, but
otherwise remains low-level (specifics in terms of code-generation strategy,
organization, ... will be clearly visible here).


however, the exact structure of this LL-IR, where the exact division of
responsibilities should be from the HL-IR, ... remain uncertain.


but, then again, it may be I have not advanced enough. for example,
implementing SSA remains a little beyond me at present, although I can
usually pull off CPS well enough as one of my earliest compilers was
structured around CPS...


however, my current compiler uses neither... all of the machinery is
centered around the stack-machine, and so most data and most godegen tasks
are accomplished by pushing things to and popping things from the stack
(with the great limitation being that large-scale code-reorganization is a
little, problematic, with this approach, and it proves a little bit of a
problem, say, to compile from an RPN-based stack machine to, say, the SysV
x86-64 calling convention absent the use of adaptor thunks...).


yet, people tout SSA, but I suspest generally don't like CPS (but, recently,
I had started trying to resolve some issues with LL-codegen, and the answer
had seemed to be that CPS is likely the better "general" answer...).


however, I am left thinking that either SSA or direct tree-based codegen are
the only real ways to natively/directly target the SysV x86-64 calling
convention (and, in fact, using CPS would seem to necessitate a very
different calling convention from SysV, which had become part of one of my
designs). I am not sure if others will agree here.


(granted, adaptor thunks are ugly and not very efficient, but they were at
least able to make it work...).


or such...

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