using lcc for compiler research
hyesoon
I'm studying a computer architecture and I'm looking for compiler
infrastructure for
a research. I want to get some opinion about using lcc for a compiler
research.
I would like to add new instructions and do some research about
instruction scheduling and register allocations. I'm wondering how
long it will take (a couple of months? one or two year?) and it's a
good idea to use lcc.
I'll be really happy to get some opinion from the current users.
Thanks.
Uncle Noah
> I want to get some opinion about using lcc for a compiler
> research.
LCC is easy to retarget, but it is better usable to very regular
architectures (single register file, no multi-output instructions
etc).
> I would like to add new instructions and do some research about
> instruction scheduling and register allocations.
There is no instruction scheduling in LCC. You should write a
scheduler by yourself (to do node reordering for each basic block e.g.
taking account hardware resource constraints that you impose).
Only instruction selection is included in LCC (i think based on Aho
work -- dynamic programming).
> I'm wondering how
> long it will take (a couple of months? one or two year?) and it's a
> good idea to use lcc.
If you get into building LCC (i use the BUILD-LCC.sh shell script in
x86/Linux and mingw32) it is a matter of one afternoon to add some
instructions and rebuild LCC. One rebuild takes about 20 min. on
Pentium-100.
A problem is with their very inappropriate documentation. No real
examples there! It is sad that there are no experienced users also.
With "experienced" i mean, any user that retargeted LCC to completely
different architecture.
You should start by understanding "mips.md" machine description.
For myself i am dropping LCC for SUIF-related compilers. Sorry, but
their lack of documentation and sensitivity leads me that way.
> I'll be really happy to get some opinion from the current users.
> Thanks.
You are welcome!
Regards
Uncle "The G.B. Man" Noah
Jonathan Buzzard
nk...@skiathos.physics.auth.gr (Uncle Noah) writes:
[SNIP]
>
> If you get into building LCC (i use the BUILD-LCC.sh shell script in
> x86/Linux and mingw32) it is a matter of one afternoon to add some
> instructions and rebuild LCC. One rebuild takes about 20 min. on
> Pentium-100.
A PIII 1GHz takes less than a minute
> A problem is with their very inappropriate documentation. No real
> examples there! It is sad that there are no experienced users also.
> With "experienced" i mean, any user that retargeted LCC to completely
> different architecture.
Er, I have personally targeted LCC to two different machines.
JAB.
--
Jonathan A. Buzzard Email: jonathan at buzzard.me.uk
Northumberland, United Kingdom. Tel: +44 1661-832195
jacob navia
"Uncle Noah" <nk...@skiathos.physics.auth.gr> wrote in message
news:b7a879e0.03090...@posting.google.com...
> their lack of documentation and sensitivity leads me that way.
Well, did you read the book?
I mean, there is a lot of documentation there.
Of course, if you like SUIF and monster packages go ahead. You will
see how tricky is it...
I have added instructions, changed the compiler in many ways, etc etc.
Is not easy, as anything worth doing. Easy stuff is too boring. But it is
obviously not impossible.
Neil Johnson
You sound like where I was three years ago. I strongly recommend LCC
as a good front-end to a compiler project. The areas you are interested
in can be accomodated in LCC, for which you really _must_ buy the book,
since that explains in great detail what the various parts of the compiler
is doing. If you are using the latest versions of the compiler (4.x) then
you will also need the addendum which explains the changes made to the
dag opcodes.
The system I have built uses LCC as a front end, generating my own
intermediate format (VSDG graphs, see
"Combined Register Allocation and Code Motion using the
Value State Dependence Graph"
Neil Johnson, Alan Mycroft, CC'03 (LNCSS 2622)
Then I do various transformations on the VSDG before finally committing it
to the VSDG-to-ARM7 code generator. Scheduling is spread out over various
phases of the compilation process, with the final scheduling being done by
the code generator.
If you choose to go this route then using LCC is pretty easy, mostly replacing
the listnodes() function calls in stmt.c and various mods to decl.c. I then
have a large function which emits VSDG nodes and edges for each LCC node.
The driver program (lcc) is modified not to call a linker, since this is handled
in later phases, especially as I am looking at whole-program optimization
so linking is done at the intermediate code level rather than at the binary
level (when it is too late for any half-decent analysis IMHO).
Cheers,
Neil
--
Neil Johnson ::::::::::::::::: University of Cambridge
PhD Research Student Computer Laboratory
http://www.cl.cam.ac.uk/~nej22 http://www.cl.cam.ac.uk
Uncle Noah
> I mean, there is a lot of documentation there.
No, i didn't. I refer to publicly available info. I don't think that
it is enough to get started rockin' 'n' rollin' with LCC.
You can buy me the LCC book if you want to :). I'm certainly not sure
yet, if i want to buy it for myself.
> Of course, if you like SUIF and monster packages go ahead. You will
> see how tricky is it...
For some things, the bigger, the better. SUIF is modular built and is
certainly no monster. I get to love it from Day 1. First examples
reveal compact code. I shall compare with GCC and LCC and i'll let you
know on that aspect. Adding new machine target is straight-forward. It
seems a lot more effort than LCC, but it adds linearly. You can get
stack in LCC if you wanna change rather unusual stuff.
I still hope to love LCC too.
>
> I have added instructions, changed the compiler in many ways, etc etc.
>
If you can give some examples please go ahead. Some of the things that
i would like to do are:
1. Irregular register architecture.
2. For simple processors, no software stack pointer. A hardware stack
for procedure return and spills target another "hidden" memory bank.
3. Special instructions that are derived with a method of mine from
some information.
3. Multiple-output instructions. Derived with a method from initial
assembly. Nothing like vector instructions though.
4. Remove support for floating-point. I will emulate them or handle by
instruction trap. I don't care!
5. Things i haven't thought of yet (lie!).
All the above have been documented in an HDL. And are working as i can
tell for now.
I also believe that the SUIF approach for separately handling post-IR
passes is likely to be good for me. Passes are distinct and you know
what you are doing.
> Is not easy, as anything worth doing. Easy stuff is too boring. But it is
> obviously not impossible.
>
Certainly not. But i'm not a developer of LCC. I want to be a user who
can take advantage of the open architecture of LCC. LCC should be only
small part of my design for evaluation flow.
Jonathan Buzzard
nk...@skiathos.physics.auth.gr (Uncle Noah) writes:
>> Well, did you read the book?
>> I mean, there is a lot of documentation there.
>
> No, i didn't. I refer to publicly available info.
The book is *publicly* available information. At least by all the
meanings of the word "publicaly" that are in my dictionary.
jacob navia
"Uncle Noah" <nk...@skiathos.physics.auth.gr> wrote in message
news:b7a879e0.03090...@posting.google.com...
> > Well, did you read the book?
> > I mean, there is a lot of documentation there.
>
> No, i didn't. I refer to publicly available info. I don't think that
> it is enough to get started rockin' 'n' rollin' with LCC.
> You can buy me the LCC book if you want to :). I'm certainly not sure
> yet, if i want to buy it for myself.
>
Well, I find then your comments about "lacking documentation" unfair.
If you do not read the docs (buy the book) I do not see how can you
complain about their non-existence...
But if you prefer SUIF go ahead...
Uncle Noah
> In article <b7a879e0.03090...@posting.google.com>,
> nk...@skiathos.physics.auth.gr (Uncle Noah) writes:
> > "jacob navia" <jacob...@jacob.remcomp.fr> wrote in message >
> >> Well, did you read the book?
> >> I mean, there is a lot of documentation there.
> >
> > No, i didn't. I refer to publicly available info.
>
> The book is *publicly* available information. At least by all the
> meanings of the word "publicaly" that are in my dictionary.
My fault. I mean "free as a bird" available. In the way Jacob Navia
(Message #7) understands it. If you want to donate my some significant
amount to buy the book please go ahead.
I'm just saying i won't buy a book of contradictory reviews (some say
it is just commented source code of LCC) for a compiler i might or
might not use.
Uncle Noah
> If you do not read the docs (buy the book) I do not see how can you
> complain about their non-existence...
>
> But if you prefer SUIF go ahead...
Dear Jacob,
did you read my comments at all? Or you just copy-pasted what is in
your interest only? I think you just did that.
Let me restate my question.
Can i describe in LCC irregular DSP architectures by providing the
appropriate machine description?
Best regards
Jonathan Buzzard
nk...@skiathos.physics.auth.gr (Uncle Noah) writes:
> jona...@buzzard.org.uk (Jonathan Buzzard) wrote in message news:<ug8ljb...@192.168.42.254>...
>> In article <b7a879e0.03090...@posting.google.com>,
>> nk...@skiathos.physics.auth.gr (Uncle Noah) writes:
>> > "jacob navia" <jacob...@jacob.remcomp.fr> wrote in message >
>> >> Well, did you read the book?
>> >> I mean, there is a lot of documentation there.
>> >
>> > No, i didn't. I refer to publicly available info.
>>
>> The book is *publicly* available information. At least by all the
>> meanings of the word "publicaly" that are in my dictionary.
>
> My fault. I mean "free as a bird" available. In the way Jacob Navia
> (Message #7) understands it. If you want to donate my some significant
> amount to buy the book please go ahead.
I suspect that judging by your email addresses neither your self or
Jacob Navia speak English as a first language. As a native English
speaker your statement just looks wrong.
> I'm just saying i won't buy a book of contradictory reviews (some say
> it is just commented source code of LCC) for a compiler i might or
> might not use.
Then borrow a copy from a library and make a decision yourself based
on the evidence, rather than hearsay. The only problem with the book
as I see it is that it describes 3.6 and not 4.x.
Yes you could say that it is comment source code, though very heavily
comment source code. It is all part of that web programming model
pioneered by Mr Knuth in his TeX book. However to say that this is
all the book is, is entirely misleading.
JAB.
--
Jonathan A. Buzzard Email: jonathan (at) buzzard.me.uk
Neil Johnson
Before you make any comments regarding the LCC book I strongly (as do others)
suggest you obtain a copy (perhaps your local library) and review it yourself.
It is a book, not a printout of the source code, and explains in detail the
internal algorithms and design choices made when the compiler was being
developed.
To answer your specific points with my opinions (which may be wrong :-)
> 1. Irregular register architecture.
Could be handled just the same was as the irregular x86 registers are handled.
> 2. For simple processors, no software stack pointer. A hardware stack
> for procedure return and spills target another "hidden" memory bank.
Well, that cuts out local variables, so you will need help from your linker
to map frames onto static memory (so no recursive calls unless you can convert
them to loops, and no calling through function pointers unless you can do
precise pointer analysis).
I suggest you add code to LCC to print out error messages if the compiler
ever finds code that needs a stack (e.g. taking the address of anything
other than global variables or functions). I'd even suggest treating
indirect function calling with care, since determining which function
is being called (so you can generate the call graph to map frames onto
static memory) is generally undecidable, even with whole-program analysis.
I may be telling you something that you already know, or maybe not. It is
difficult to tell without knowing your purpose or affiliation or background.
> 3. Special instructions that are derived with a method of mine from
> some information.
If you write additional rules in the machine description that map the
LCC DAG ops onto your special instructions then that should be possible.
> 3. Multiple-output instructions. Derived with a method from initial
> assembly. Nothing like vector instructions though.
If you can represent these in plain C then quite possibly. There is not
a great deal of dataflow analysis done by LCC so you might be forced to
add that yourself.
> 4. Remove support for floating-point. I will emulate them or handle by
> instruction trap. I don't care!
So create pseudo-rules in the MD file that generates calls to your FP library.
That way you can write floating point operations, and LCC will emit
calls to the FP library. How you implement FP registers is another matter
(perhaps map them to a static array in memory, since you don't have local
stack memory to use).
I once wrote an 80186 backend that did exactly this.
Regards,
Uncle Noah
> Jacob Navia speak English as a first language. As a native English
> speaker your statement just looks wrong.
So? Got any problem with that?
> > bla bla bla
More important, you fail to argue on more important issues in our little chit-chat.
Best regards
Jonathan Buzzard
nk...@skiathos.physics.auth.gr (Uncle Noah) writes:
>> Jacob Navia speak English as a first language. As a native English
>> speaker your statement just looks wrong.
>
> So? Got any problem with that?
No I was just passing a comment on why two people where able to
make the same mistake of language, while all I saw was a blantently
false alegation.
Got any problem with than?
>> > bla bla bla
>
> More important, you fail to argue on more important issues in our little
> chit-chat.
Here goes but bear in mind NDA's restrict what I can say.
> 1. Irregular register architecture.
No problem.
> 2. For simple processors, no software stack pointer. A hardware stack
> for procedure return and spills target another "hidden" memory bank.
Done two machines that don't have any sort of stack pointer whatsoever.
> 3. Special instructions that are derived with a method of mine from
> some information.
You will have to be more specific here.
> 3. Multiple-output instructions. Derived with a method from initial
> assembly. Nothing like vector instructions though.
Tricky, would need to see an example of what you mean.
> 4. Remove support for floating-point. I will emulate them or handle by
> instruction trap. I don't care!
Well just don't implement and op+F+size nodes then. The compiler will
barf if you try any floating point in your code, but then you are
not doing it anyway.
A better idea is have the compiler spit out calls to your floating
point so you can just use floating point code as normal. I have done
this myself, though you need a minor patch to make sure all the
floating point calls are unrolled.
Fergus Henderson
>I'm studying a computer architecture and I'm looking for compiler
>infrastructure for
>a research. I want to get some opinion about using lcc for a compiler
>research.
>I would like to add new instructions and do some research about
>instruction scheduling and register allocations.
Using lcc is probably easier for many tasks than using more complicated
systems such as GCC. However, for analyzing compiler optimizations,
hardware design, or other performance issues, I do not think it is a
very good choice, because lcc is not an optimizing compiler, and so the
results of any benchmarks would not be very relevant to optimizing
compilers.
--
Fergus Henderson <f...@cs.mu.oz.au> | "I have always known that the pursuit
The University of Melbourne | of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.