View previous topic :: View next topic |
Author |
Message |
Wienczny
Joined: 10 Apr 2004 Posts: 35
|
Posted: Fri May 21, 2004 6:35 am Post subject: DCC Design |
|
|
This is the overall design we could use:
The compiler consists of modules, which are compiled into shared objects.
The basic module types are frontends, optimizer stages, backends.
The compiler driver should be a shared object, too. This should make it easy to embed it into IDEs. A console version will be included.
The compiler driver should be able to understand different project files for example make, scons, aap, maybe a new one.
The internal parts of the compiler:
Frontends generates a language independent AST. Some Optimizations will be run (Deadcode elimination etc.) . After that the AST is converted into SSA form for further optimization. At the end it is converted into a register machine language, again optimized and given to the backend for instruction selecting, register allocation etc.
Advantages:
Easy to use as XPlattform compiler.
Possibly creation of fast code.
Disadvantages:
Maybe not the fastest compile times.
What do you think about it?
[/code] |
|
Back to top |
|
|
Derek Parnell
Joined: 22 Apr 2004 Posts: 408 Location: Melbourne, Australia
|
Posted: Sun May 23, 2004 7:47 pm Post subject: |
|
|
Like all non-trivial projects, work out what the goals are first. That way you know when to stop (or give up).
Things to consider...
Cross platform: How important. Does platform only include OS? Or is hardware included too. (eg. Intel, Palm, Motorola, ...) And what about compiling on one platform but targeting another?
Optimization: Is execution speed more important that executable size?
Compilation speed: Is this important?
Which object code format(s)?
Debugging support?
Profiling support? Times and counts?
I assume that the DCC is a collabarative effort, so the source code control is an issue (smaller modules are easier to checkout/in but increase the need for an API approach rather than public variables.) etc...
User Interface: Multi-Language support for error messages? Output reports? - assembler listing, object maps, symbol table, line-numbered source code, optimization list, inlined list, environment stats (mem used, durations, ...)
Precompiled 'headers'?
Incremental compilation?
IDE support?
... just to name a few
Once you sort out what are the goals, you can design a framework that directs the implementation of those goals. _________________ --
Derek
skype name: derek.j.parnell |
|
Back to top |
|
|
Wienczny
Joined: 10 Apr 2004 Posts: 35
|
Posted: Mon May 24, 2004 5:22 am Post subject: |
|
|
Derek Parnell wrote: |
Cross platform: How important. Does platform only include OS? Or is hardware included too. (eg. Intel, Palm, Motorola, ...) And what about compiling on one platform but targeting another?
|
I think that cross platform is important. Using D pretty much ensures that it can be run on different OS and maybe hardware. The concept of a shared obeject as backend should make it easy to compile on one platform targeting another.
Derek Parnell wrote: |
Optimization: Is execution speed more important that executable size?
Compilation speed: Is this important?
|
If you look at the speed that harddisks and ram grown you will see that for normal computers running speed is more important.
Embedded devices have other constrains. There should be different optimizer chains
Compilation speed is important for development but not release code.
Derek Parnell wrote: |
Which object code format(s)?
Debugging support?
Profiling support? Times and counts?
|
It will have to support the systems default object code format eg. ELF on Linux, PEF on Mac and PE on Windows. The output format for VMs (Java .Net) is defined by the VM.
I don't want to reinvent the wheel of debugging and profilling.
Derek Parnell wrote: |
I assume that the DCC is a collabarative effort, so the source code control is an issue (smaller modules are easier to checkout/in but increase the need for an API approach rather than public variables.) etc...
|
You are absolutly right. The API is something I would like to discuss in this thread.
Derek Parnell wrote: |
User Interface: Multi-Language support for error messages? Output reports? - assembler listing, object maps, symbol table, line-numbered source code, optimization list, inlined list, environment stats (mem used, durations, ...)
|
Multi Language support should be a feature. The output reports should be included as they are needed for debugging.
Derek Parnell wrote: |
Precompiled 'headers'?
Incremental compilation?
|
Precompiled headers are an frontend issue.
I should have a look incremental compilation
Derek Parnell wrote: |
IDE support?
|
The compiller driver will be a shared object. It should be easy to implement support in a IDE |
|
Back to top |
|
|
KTC
Joined: 04 Jun 2004 Posts: 3 Location: UK
|
Posted: Fri Jun 04, 2004 3:43 pm Post subject: |
|
|
Wienczny wrote: | It will have to support the systems default object code format eg. ELF on Linux, PEF on Mac and PE on Windows. The output format for VMs (Java .Net) is defined by the VM.
I don't want to reinvent the wheel of debugging and profilling. | No, which object code format? For example on Windows:
COFF? (which version?) OMF?
For debugging, what type of debugging info. ?
CodeView? (which version?) COFF? FPO? etc.. _________________ Say NO to software patents !!
High Level Assembly |
|
Back to top |
|
|
Wienczny
Joined: 10 Apr 2004 Posts: 35
|
Posted: Fri Jun 04, 2004 5:05 pm Post subject: |
|
|
KTC wrote: | Wienczny wrote: | It will have to support the systems default object code format eg. ELF on Linux, PEF on Mac and PE on Windows. The output format for VMs (Java .Net) is defined by the VM.
I don't want to reinvent the wheel of debugging and profilling. | No, which object code format? For example on Windows:
COFF? (which version?) OMF?
For debugging, what type of debugging info. ?
CodeView? (which version?) COFF? FPO? etc.. |
I would say that we use different object code formats. This would be handled by the backend backend . I suggest to make a pluggable objectcode writer.
The standard output should be COFF on Win32 as M$ uses it and most applications understand it. OMF is (only) used by Borland. On Linux ELF would be standard. Macintosh uses Mach-O.
The possible debbuging infos should be COFF, Codeview and Dwarf. |
|
Back to top |
|
|
KTC
Joined: 04 Jun 2004 Posts: 3 Location: UK
|
Posted: Sat Jun 05, 2004 12:12 pm Post subject: |
|
|
Yeah, that sounds good.
Quote: | The standard output should be COFF on Win32 as M$ uses it and most applications understand it. OMF is (only) used by Borland. | Hey, DMC & DMD both uses OMF Plus I think mingw/cygwin & OpenWatcom too
Anyway, probably non exist at this early stage but if there's anyway one can do that doesn't involve the programming side of things, let me know. (I can't contribute to the programming side coz I need to learn things like .... D, algorithms, data structures, FSM, parsing, the different file format etc. first! Not that I'm not planning to, just might take 6-12 months first ) _________________ Say NO to software patents !!
High Level Assembly |
|
Back to top |
|
|
Wienczny
Joined: 10 Apr 2004 Posts: 35
|
Posted: Sat Jun 05, 2004 11:29 pm Post subject: |
|
|
KTC wrote: |
Anyway, probably non exist at this early stage but if there's anyway one can do that doesn't involve the programming side of things, let me know. (I can't contribute to the programming side coz I need to learn things like .... D, algorithms, data structures, FSM, parsing, the different file format etc. first! Not that I'm not planning to, just might take 6-12 months first ) |
You could help me designing the data structures involved.
I'm not quite sure how they should be implemented, because they should fit to more than one language. One possibility would be to use the toolchain GCC has.
C++-Tree -> Generic Tree -> Gimple (SSA) -> RTL
Should we do it exactly the same way as GCC or should we reinvent it?
GCC does not use object oriented programming, we should use it in a D implementation
Stephan
p.s.: You are right about OMF. |
|
Back to top |
|
|
KTC
Joined: 04 Jun 2004 Posts: 3 Location: UK
|
Posted: Mon Jun 07, 2004 5:08 pm Post subject: |
|
|
I can try
Have got uni exams and things so will take a look into it next week. About OO, for modules that's appropriate, of course, but I guess you already decided that anyway _________________ Say NO to software patents !!
High Level Assembly |
|
Back to top |
|
|
Wienczny
Joined: 10 Apr 2004 Posts: 35
|
Posted: Mon Jun 07, 2004 7:39 pm Post subject: |
|
|
KTC wrote: | I can try
Have got uni exams and things so will take a look into it next week. About OO, for modules that's appropriate, of course, but I guess you already decided that anyway |
*g*
There are 3 interfaces for modules (Frontend, Optimizer, Backend). Maybe there will be more....
A compiler module has one of these as base class and is compiled into a shared object. This way it is possible to access them using a simple object broker (D needs an advanced one). The compiler driver is then able to dynamically load needed modules. You could do that in plain C whitout any OO but that does not look nice
The problem is the interface between the module interfaces.
What data structures do the frontends generate?
What data structures does the optimizer use internally?
What does the backend accept?
I looked at GCC, but was not satisfied with their work.
What do you think about that.
Stephan
P.s.:I am at present busy at a project, for which I am paid... could be a week or two. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|