Re: What's lacking: a good intermediate form

> At some time though, I'd want a direct comparison of a full
> implementation of my language vs. C and C++ and probably D, so the
> itch is always there to do a full-blown implementation. That would
> be a milestone/assessment juncture.


> There used to be something called "Assembly Language Toolkit" (a
> commercial product). A quick google on that though doesn't find
> it. I remember it from the late '80's. It was a library of assembly
> routines callable from C. It may have even been inline assembly, I
> never used it. Something like it though for compiler implementers
> seems lucrative. I mean, how many ways are there to set up a call
> stack on x86? And why would I want to bother with that as a language
> designer?


Creating a language is like peeling an onion. At every layer there are
new and exciting problems below that affect the choices made several
layers ago. The very first thing is the need to have an exceptional
set of good reasons for every feature and then an extremely clear view
of how the pieces are connected together to express an application
idea in an unambiguous way. Languages do not have to be complicated
just very clear with an understanding to a high level of detail..


To answer the last two questions.
> how many ways are there to set up a call stack on x86?


Many many ways. In the more complex code generators arguments many be
re-entrant, re-ordered, stack based, register based, allocated to a
fixed address at compile time or a combination. Data flow analysis my
determine call stack organization for each function. And why not, the
number of processor cycles available to a compiler allows serious
optimization algorithms to be implemented to make a compiler
competitive in some application related benchmark.


> And why would I want to bother with that as a language designer?


A language designer needs to be able to visualize two things. How the
language will describe an application and how the application will be
mapped on a target. Consideration needs to be given to the target
processor. If the processor target is a constraint then the language
translation needs to recognize the processors strengths and limits.
Language designers need to understand how calls are made and
the complex trade-offs between inline and called functions. Efficient
argument passing can alter some of the choices. So can cache and
pipeline dynamics alter these choices and in the end they matter.


Regards,


--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com

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