oopic-compiler-devel Mailing List for OOPic Compiler (Page 2)
Status: Planning
Brought to you by:
ndurant
Menu
▾
▴
oopic-compiler-devel — A mailing list for discussion of design and development of the OOPic compiler
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
(36) |
May
(52) |
Jun
(17) |
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
(6) |
|---|
|
From: Neil D. <nd...@us...> - 2004-06-01 15:02:58
|
I've been reading more about Python, and it really does look like a good implementation language for the OOPic compiler. I'd be all for going for it, but I'd really like to hear Andy's thoughts on it! I notice that you can call C functions from Python and vice versa, relatively easily, meaning that if there's anything we find we really need C for, then we can do it in C. Details here: <http://docs.python.org/ext/ext.html> I'm really keen to get on with development, but deciding on the implemntation language is pretty critical! Andy, are you still with us? Neil -- Neil Durant <nd...@us...> |
|
From: Neil D. <nd...@us...> - 2004-05-28 21:58:45
|
Brian wrote: > On Fri, May 28, 2004 at 10:30:38PM +0100, Neil Durant wrote: > > The question of whether we ship tools we don't maintain (eg Python if we go > > down that route, *lex, yacc/bison etc) is a tricky one. > > I'm not aware of any projects that use Python *and* package Python as > part of the distribution (I've not come across any Perl apps either > that do this). I believe the way to handle this is to (1) ensure > backwards-compatibility as versions of system tool X change, and > (2) specify a minimum version of support for that system tool. Agreed. > If you start packaging the system tools as part of the toolkit, it > will make it look like you offer support for those system tools as > well. That is probably a closed can of worms asking to be opened. Agreed. > Most *nix users would not stand to have system tools installed, and > would probably resist any attempt to do so. Personally, I would not > want to install any application or toolkit on my *nix or OS X boxes > that required me to use the system tools as shipped with the app. Agreed - and some people might be suspicious of us distributing things like Perl or Python or anything like that, which would be picked up and used by system scripts etc. > You can't hold everyone's hands. The end user must take some > responsiblity for making sure their system tools support the toolkit. > We can help through the installation process to identify deficiencies > a particular system may have, and direct the end user to where they > can obtain the system tools necessary for the toolkit. I guess we could hold the Windows users' hands - they're unlikely to have any dependencies installed already (unlike any *nix systems). Neil -- Neil Durant <nd...@us...> |
|
From: Brian <bri...@po...> - 2004-05-28 21:44:38
|
On Fri, May 28, 2004 at 10:30:38PM +0100, Neil Durant wrote: > The question of whether we ship tools we don't maintain (eg Python if we go > down that route, *lex, yacc/bison etc) is a tricky one. I'm not aware of any projects that use Python *and* package Python as part of the distribution (I've not come across any Perl apps either that do this). I believe the way to handle this is to (1) ensure backwards-compatibility as versions of system tool X change, and (2) specify a minimum version of support for that system tool. If you start packaging the system tools as part of the toolkit, it will make it look like you offer support for those system tools as well. That is probably a closed can of worms asking to be opened. > If someone's > installing our stuff and already has some of those tools installed, do they > use ours or their existing ones? That's a road we don't want to travel down. If we do our part right, it won't matter what version of tools the end user has installed, as long as conditions (1) and (2) above are met. Most *nix users would not stand to have system tools installed, and would probably resist any attempt to do so. Personally, I would not want to install any application or toolkit on my *nix or OS X boxes that required me to use the system tools as shipped with the app. > Plus, how completely would we support > platforms? If we're shipping platform dependent tools (the Python > interpreter for example, if we use Python) then we could potentially be > shipping a dozen different ones (for different Linux distributions, > FreeBSD, etc etc). You can't hold everyone's hands. The end user must take some responsiblity for making sure their system tools support the toolkit. We can help through the installation process to identify deficiencies a particular system may have, and direct the end user to where they can obtain the system tools necessary for the toolkit. --Brian |
|
From: Neil D. <nd...@us...> - 2004-05-28 21:31:06
|
Interesting idea. This would also encourage people to join in with the development effort, if the 'toolkit' they download contains everything, any extra tools, all documentation, known bugs (if any!), new features for each release etc. The question of whether we ship tools we don't maintain (eg Python if we go down that route, *lex, yacc/bison etc) is a tricky one. If someone's installing our stuff and already has some of those tools installed, do they use ours or their existing ones? Plus, how completely would we support platforms? If we're shipping platform dependent tools (the Python interpreter for example, if we use Python) then we could potentially be shipping a dozen different ones (for different Linux distributions, FreeBSD, etc etc). You're right about the maintenance effort, but it shouldn't be problematic if we're using version control (CVS or whatever). D. Daniel McGlothin wrote: > What I had in mind was: > > a. The tools the project generates > b. The tools the project uses to construct (a). > c. The support environment stuff required for (b). > > Thus, given recent discussion, it would include compiler, downloader, IDE (if > generated), source for the previous, Python (for Win, Max, Un*x), *lex, *yac, > etc. Don't forget to include documentation for all. > > The thinking is that the easier it is for a relative novice to acquire/use, the > more wide-spread our toolchain may become. > > Of course, there is a maintenance effort to keep track of current releases of > the above. > > Best Regards, > Daniel > > > -----Original Message----- > > From: oop...@li... > > [mailto:oop...@li...]On Behalf Of > > Neil Durant > > Sent: Friday, May 28, 2004 4:40 PM > > To: oop...@li... > > Subject: Re: [Oopic-compiler-devel] Hello from the new guy > > > > > > D. Daniel McGlothin wrote: > > > Whatever is done, I think I'd recommend a complete toolkit as the > > > end-deliverable. Something like what Eric Weddington did for the AVR > > > microprocessor with the WinAVR toolkit that bundles all of the > > required/optional > > > components (see www.AVRfreaks.net and > > http://sourceforge.net/projects/winavr). > > > > What tools did you have in mind, besides a compiler and possible IDE ? > > > > I guess the cross-platform OOPic code uploader would be one tool. > > > > And one thing I think could be useful would be an assembler that assembles > > the Forth-like OOPic op-codes into hex. It would be trivial to do, and it > > could be useful to test ideas before implementing new language features, > > and testing out optimisation techniques etc. > > > > Any other ideas? > > > > Neil > > -- > > Neil Durant > > <nd...@us...> > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by: Oracle 10g > > Get certified on the hottest thing ever to hit the market... Oracle 10g. > > Take an Oracle 10g class now, and we'll give you the exam FREE. > > http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click > > _______________________________________________ > > Oopic-compiler-devel mailing list > > Oop...@li... > > https://lists.sourceforge.net/lists/listinfo/oopic-compiler-devel > > > > > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: Oracle 10g > Get certified on the hottest thing ever to hit the market... Oracle 10g. > Take an Oracle 10g class now, and we'll give you the exam FREE. > http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click > _______________________________________________ > Oopic-compiler-devel mailing list > Oop...@li... > https://lists.sourceforge.net/lists/listinfo/oopic-compiler-devel > -- Neil Durant <nd...@us...> |
|
From: D. D. M. <dd...@mc...> - 2004-05-28 20:59:05
|
What I had in mind was: a. The tools the project generates b. The tools the project uses to construct (a). c. The support environment stuff required for (b). Thus, given recent discussion, it would include compiler, downloader, IDE (if generated), source for the previous, Python (for Win, Max, Un*x), *lex, *yac, etc. Don't forget to include documentation for all. The thinking is that the easier it is for a relative novice to acquire/use, the more wide-spread our toolchain may become. Of course, there is a maintenance effort to keep track of current releases of the above. Best Regards, Daniel > -----Original Message----- > From: oop...@li... > [mailto:oop...@li...]On Behalf Of > Neil Durant > Sent: Friday, May 28, 2004 4:40 PM > To: oop...@li... > Subject: Re: [Oopic-compiler-devel] Hello from the new guy > > > D. Daniel McGlothin wrote: > > Whatever is done, I think I'd recommend a complete toolkit as the > > end-deliverable. Something like what Eric Weddington did for the AVR > > microprocessor with the WinAVR toolkit that bundles all of the > required/optional > > components (see www.AVRfreaks.net and > http://sourceforge.net/projects/winavr). > > What tools did you have in mind, besides a compiler and possible IDE ? > > I guess the cross-platform OOPic code uploader would be one tool. > > And one thing I think could be useful would be an assembler that assembles > the Forth-like OOPic op-codes into hex. It would be trivial to do, and it > could be useful to test ideas before implementing new language features, > and testing out optimisation techniques etc. > > Any other ideas? > > Neil > -- > Neil Durant > <nd...@us...> > > > ------------------------------------------------------- > This SF.Net email is sponsored by: Oracle 10g > Get certified on the hottest thing ever to hit the market... Oracle 10g. > Take an Oracle 10g class now, and we'll give you the exam FREE. > http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click > _______________________________________________ > Oopic-compiler-devel mailing list > Oop...@li... > https://lists.sourceforge.net/lists/listinfo/oopic-compiler-devel > > |
|
From: Neil D. <nd...@us...> - 2004-05-28 20:40:55
|
D. Daniel McGlothin wrote: > Whatever is done, I think I'd recommend a complete toolkit as the > end-deliverable. Something like what Eric Weddington did for the AVR > microprocessor with the WinAVR toolkit that bundles all of the required/optional > components (see www.AVRfreaks.net and http://sourceforge.net/projects/winavr). What tools did you have in mind, besides a compiler and possible IDE ? I guess the cross-platform OOPic code uploader would be one tool. And one thing I think could be useful would be an assembler that assembles the Forth-like OOPic op-codes into hex. It would be trivial to do, and it could be useful to test ideas before implementing new language features, and testing out optimisation techniques etc. Any other ideas? Neil -- Neil Durant <nd...@us...> |
|
From: Neil D. <nd...@us...> - 2004-05-28 20:35:39
|
Having done a bit more pondering, just following up my own posting... Neil Durant wrote: > Brian wrote: > > Has any consideration been given to writing some or all of this project > > in a truly portable language such as Python? > > It would certainly make cross-platform support easy, as you say. However, > some points against might be: > > 1) How many of us know Python well enough to embark upon a compiler-writing > project? > > 2) We would presumably require end-users to have Python installed in order > to run the compiler. This shouldn't be a problem, but it would complicate > matters from an installer point of view. The converse of point (2) is that we would only need to ship one compiler, for any platform, ie we wouldn't even need different builds for different platforms. The more I think about this Python idea, the more intrigued I am. Andy, any thoughts? Neil -- Neil Durant <nd...@us...> |
|
From: D. D. M. <dd...@mc...> - 2004-05-26 12:06:31
|
Hi Brian, > I'd be interested to hear Andy's/Daniel's thoughts on Python. I guess that is my cue.... I'm personally indifferent to language choice. My experience has led to a somewhat jaded view of the intensity of most of the 'language wars'; and has shown me all require a mastery of the grammar/syntax and an appreciation of the applicability of the specific competency of the tool to the application (remember the adage, when a carpenter has only a hammer, everything looks like a nail). I'll be learning a bit about compiler design & code generation whatever the decisions. Whatever is done, I think I'd recommend a complete toolkit as the end-deliverable. Something like what Eric Weddington did for the AVR microprocessor with the WinAVR toolkit that bundles all of the required/optional components (see www.AVRfreaks.net and http://sourceforge.net/projects/winavr). Why I'm involved: I am one of those that got burnt by a botched IDE installation, but mostly am interested in the puzzle of the figuring out the internals of the OOpic, especially the VC stuff. Best Regards, Daniel |
|
From: Neil D. <nd...@us...> - 2004-05-26 11:29:03
|
Brian wrote: > On Wed, May 26, 2004 at 05:29:26AM +0100, Neil Durant wrote: > > Actually speaking of a code uploader, it would be nice to have one that > > work on different platforms, and that could use either parallel or serial > > SCP for program uploads. Should we develop one of these too? > > That would be something I'd be interested in working on! I guess the SCP side of it wouldn't be too hard - just sending the appropriate commands to the appropriate serial port. However the parallel port side of it would require implementing an I2C master, which wouldn't be quite so straightforward. Neil -- Neil Durant <nd...@us...> |
|
From: Brian <bri...@po...> - 2004-05-26 04:59:48
|
On Wed, May 26, 2004 at 05:29:26AM +0100, Neil Durant wrote: > Actually speaking of a code uploader, it would be nice to have one that > work on different platforms, and that could use either parallel or serial > SCP for program uploads. Should we develop one of these too? That would be something I'd be interested in working on! --Brian |
|
From: Neil D. <nd...@us...> - 2004-05-26 04:44:25
|
Me again... I don't think my reply to this was especially clear (it's 5.38am here - long night!). Brian wrote: > There's been talk of writing code to support several different platforms, > including DOS, Windows, Linux, and Mac OS. Is it the group's goal to > write a replacement IDE/compiler, or to make the OOPic accessible to > platforms not currently supported? I think our goal is to achieve both of those aims (although initially just for the compiler). We want a single compiler, written from the ground up, that will work on all popular platforms, so it would make the OOPic accessible to non-Windows platforms, and would provide an alternative to the existing tools (and a superior alternative!) on the Windows platform. And in doing this we want to improve the language support substantially, and make error reporting better (that one won't be hard!!). Neil -- Neil Durant <nd...@us...> |
|
From: Neil D. <nd...@us...> - 2004-05-26 04:29:38
|
Brian wrote: > Neil asked me to introduce myself as the new guy...there's not much to > say, other than my programming background is mostly in algorithms and > signal/image processing, with a smattering of languages (C++ and Perl > are my faves, though). My interests in this group lie mainly with a > port that will work under *nix and Mac OS X. I currently run the > OOPic IDE under wine, but I would prefer something a bit more stable! Welcome to the group! > --There's been talk of writing code to support several different > platforms, including DOS, Windows, Linux, and Mac OS. Is it the > group's goal to write a replacement IDE/compiler, or to make the OOPic > accessible to platforms not currently supported? I'd be mostly > interested in helping with a port that runs on a platform not > currently supported... I think each of us have our own reasons. However I think the most fundamental reason for this project is that the only available compiler for the OOPic is closed-source and there is little chance of much development in that area from Savage Innovations. So getting bugs fixed, better language support, and support for non-Windows platforms are all pretty remote hopes. Writing a new, open-source compiler means that if someone has a need, for example to run it on some obscure BSD operating system, or if they want an OOPic compiler for a language other than C/Java/Basic, it can be done without too many headaches. It opens up the possibility of each of our various personal interests becoming a reality. My own interest is primarily to provide a good solid OOPic compiler that runs under Linux. I also have a Mac PowerBook, and would love the compiler to run on that too. My other interests are in improving language support, so that we can use more standard C syntax, we can declare arrays which work in EEPROM (but use standard C syntax), we can use #includes etc. Once you decide to write a new compiler, loads of opportunities appear for language improvements. The other thing is that we're currently focussing on the compiler aspect, which is currently only available as a closed-source product. Along with a good programmer's editor and a code uploader, it's basically all you need to develop for the OOPic on any platform we can support, so in doing the compiler we open up the OOPic to people on all those platforms. Actually speaking of a code uploader, it would be nice to have one that work on different platforms, and that could use either parallel or serial SCP for program uploads. Should we develop one of these too? Perhaps later on we'll look into creating a cross-platform IDE that doesn't crash and doesn't rely on VB! > --I noticed the consensus is to use C for this project. While I'm > comfortable with that, won't this become something of a maintenance > nightmare to support several different platforms? It shouldn't be. Remember, this is only for the compiler, which takes in one or more text files, and outputs a binary file and perhaps a text file or two. No user interface beyond a few command-line parameters!! These are things the C Standard Library can handle, and targetting different platforms should be easy, and perhaps trivial. It also means we can ship a single executible file if we want to, with no dependencies or fancy installer required. > Has any consideration been given to writing some or all of this project > in a truly portable language such as Python? There are several Python > parser generators available (http://www.python.org/topics/parsing.html) > that would make porting to different platforms a snap It's worth considering, definitely. Although we all agreed on C pretty quickly, there wasn't much discussion about alternatives. I don't know Python, but I've looked at it a little in the past and it's one of those languages I've wanted to learn for a while. It would certainly make cross-platform support easy, as you say. However, some points against might be: 1) How many of us know Python well enough to embark upon a compiler-writing project? 2) We would presumably require end-users to have Python installed in order to run the compiler. This shouldn't be a problem, but it would complicate matters from an installer point of view. I'd be happy to go down the Python route if that became the general concensus, but I think there'd be a bit of a learning curve involved. I can imagine some of the features Python has over C such as OO support, powerful containers such as hashes, queues, lists etc, would make some aspects of development considerably easier. I'd be interested to hear Andy's/Daniel's thoughts on Python. I think it's a very interesting idea, and could certainly be beneficial, once we're over the initial learning curve. > ...and would ease the support for several GUI front-ends (there is Python > "glue" for many GUI libraries, including Mac's native libraries and a > number of libraries, such at GTK+). Work on a GUI front-end could be > done pretty much independently from the parser/compiler/loader once an > interface has been designed; working in parallel on the front end and > back end would really save time and effort. Well at the moment, as I say, we're focussing entirely on the compiler, which should ideally be a command-line driven tool that anyone can use with any editor, IDE or whatever. So I don't think the advantages gained by having cross-platform GUI toolkits available really counts for the compiler. Having said that, using a language that supported (or had libraries for) useful containers on different platforms could certainly be beneficial. However if/when we were to develop an IDE, then Python could certainly be a strong contender. We would definitely have to use a language where there was a strong cross-platform GUI toolkit available. Some contenders might be: * Python * Java * C++ with the QT GUI toolkit (runs on Win, *nix, OSX) > Hope no one take offense to these observations...I'm willing to help > with whatever I can. Not at all, we're all friends here and all ideas are worth airing and discussing. Neil -- Neil Durant <nd...@us...> |
|
From: Brian <bri...@po...> - 2004-05-26 02:15:49
|
All-- Neil asked me to introduce myself as the new guy...there's not much to say, other than my programming background is mostly in algorithms and signal/image processing, with a smattering of languages (C++ and Perl are my faves, though). My interests in this group lie mainly with a port that will work under *nix and Mac OS X. I currently run the OOPic IDE under wine, but I would prefer something a bit more stable! I've read through most of the archives, and it sounds like you all have put a lot of thought into this project. I do have a couple of observations: --There's been talk of writing code to support several different platforms, including DOS, Windows, Linux, and Mac OS. Is it the group's goal to write a replacement IDE/compiler, or to make the OOPic accessible to platforms not currently supported? I'd be mostly interested in helping with a port that runs on a platform not currently supported... --I noticed the consensus is to use C for this project. While I'm comfortable with that, won't this become something of a maintenance nightmare to support several different platforms? Has any consideration been given to writing some or all of this project in a truly portable language such as Python? There are several Python parser generators available (http://www.python.org/topics/parsing.html) that would make porting to different platforms a snap, and would ease the support for several GUI front-ends (there is Python "glue" for many GUI libraries, including Mac's native libraries and a number of libraries, such at GTK+). Work on a GUI front-end could be done pretty much independently from the parser/compiler/loader once an interface has been designed; working in parallel on the front end and back end would really save time and effort. Hope no one take offense to these observations...I'm willing to help with whatever I can. --Brian |
|
From: <ben...@id...> - 2004-05-25 08:43:47
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
|
From: Andrew P. <wa...@ic...> - 2004-05-20 22:33:15
|
Sounds promising. I'll have a look at it. At 12:25 PM 5/20/2004 +0100, Neil Durant wrote: >I've been looking to see if there are any simple open source C compilers >out there that we could use as a starting point for our OOPIC compiler, or >at least use it for ideas etc. > >Anyway, I've found one, which compiles to assembler for a stack-based >virtual machine: > > <http://fabrice.bellard.free.fr/fbcc.html> > >It uses Flex/Bison for parsing, and implements ANSI C. It's released under >the GPL licence so there's no reason why we can use any or as much or the >source code as we need. > >As it compiles to assembler for a stack-based VM, I thought it may be >pretty close to what we need - we may just have to re-write the code >generation stuff to get it to generate OOPIC "assembler". > >I thought I'd post this so we can all have a look at it. We should only >use something like this if we fully understand how it works, and if it does >actually work! The code looks fairly clean and well-written (from a quick >browse around the source files), so it all looks promising. > >At the very least we can use their Flex/Bison grammar files for parsing >ANSI C and creating the internal representation of the code. > >Thoughts? > >Neil >-- >Neil Durant ><nd...@us...> |
|
From: Neil D. <nd...@us...> - 2004-05-20 11:25:54
|
I've been looking to see if there are any simple open source C compilers out there that we could use as a starting point for our OOPIC compiler, or at least use it for ideas etc. Anyway, I've found one, which compiles to assembler for a stack-based virtual machine: <http://fabrice.bellard.free.fr/fbcc.html> It uses Flex/Bison for parsing, and implements ANSI C. It's released under the GPL licence so there's no reason why we can use any or as much or the source code as we need. As it compiles to assembler for a stack-based VM, I thought it may be pretty close to what we need - we may just have to re-write the code generation stuff to get it to generate OOPIC "assembler". I thought I'd post this so we can all have a look at it. We should only use something like this if we fully understand how it works, and if it does actually work! The code looks fairly clean and well-written (from a quick browse around the source files), so it all looks promising. At the very least we can use their Flex/Bison grammar files for parsing ANSI C and creating the internal representation of the code. Thoughts? Neil -- Neil Durant <nd...@us...> |
|
From: Neil D. <nd...@us...> - 2004-05-12 22:26:19
|
Andrew Porrett wrote: > At 08:17 PM 5/12/2004 +0100, Neil Durant wrote: > >I say we go for our ideal standard C to begin with, almost as a proof of > >concept. Then once we're happy it's all working then the other 5 languages > >(or more!) can be filled in. > > Works for me! Excellent! Ok, so if this project is going to fall naturally into two development halves - me doing the parsing and internal representation building, and you (Andy) doing the code gegeration and optimization, then we're going to have to discuss what data structures you're going to need to start generating code. This will then allow me to get going on the parsing side of things. Have you had chance to think about what kinds of data structures you'll need for code generation? Neil -- Neil Durant <nd...@us...> |
|
From: Andrew P. <wa...@ic...> - 2004-05-12 21:12:39
|
At 08:17 PM 5/12/2004 +0100, Neil Durant wrote: >I say we go for our ideal standard C to begin with, almost as a proof of >concept. Then once we're happy it's all working then the other 5 languages >(or more!) can be filled in. Works for me! ...Andy |
|
From: Neil D. <nd...@us...> - 2004-05-12 19:17:24
|
Andrew Porrett wrote: > At 03:15 AM 5/12/2004 +0100, Neil Durant wrote: > >I think we'll be able to handle the original Savage C/BASIC/Java syntaxen > >using a preprocessor like Andy's, which would then output grammar which is > >compatible with our new compiler. > > I would expect that you could handle the original syntax by taking your > definitions for C / BASIC / Java and just modifuing them a bit. IOW, you > would have 6 languages to support. That would be the other way of doing it. Ironically that would mean that some of the grammar-checking rules for the Savage C language module would have to spit out an error for certain perfectly legal C syntax... :-) I say we go for our ideal standard C to begin with, almost as a proof of concept. Then once we're happy it's all working then the other 5 languages (or more!) can be filled in. Neil -- Neil Durant <nd...@us...> |
|
From: Andrew P. <wa...@ic...> - 2004-05-12 14:21:29
|
At 03:01 AM 5/12/2004 +0100, Neil Durant wrote: >I'm sure we'll need a lot more than this, but my brain is begging for >sleep!! Andy, can you think what other structures we'll need to start code >generation? Eh? It's 10 AM and my brain isn't awake yet. ...Andy |
|
From: Andrew P. <wa...@ic...> - 2004-05-12 14:21:28
|
At 03:15 AM 5/12/2004 +0100, Neil Durant wrote: >I think we'll be able to handle the original Savage C/BASIC/Java syntaxen >using a preprocessor like Andy's, which would then output grammar which is >compatible with our new compiler. I would expect that you could handle the original syntax by taking your definitions for C / BASIC / Java and just modifuing them a bit. IOW, you would have 6 languages to support. >Of course, we should be trying to persuade people to switch to our more >complete and standard syntax, but we should also aim to support the Savage >"legacy" syntax... :-) Agreed. ...Andy |
|
From: Andrew P. <wa...@ic...> - 2004-05-12 14:21:27
|
At 09:13 PM 5/11/2004 -0400, D. Daniel McGlothin wrote: >A couple of quick thoughts. > >1. lack of support for the three syntax styles Savage implemented is >probably a non-starter (unless we have the IDE selecting between the OOpicMK >compiler and this one). As it is now, the user must specify the syntax; we >can require the same as a command line. Or possibly use a token in the >sourcecode similar to what Parallax did with their new PBasic syntax and the >firmware revisions, and let the preprocessor pick it out. Using the existing compiler's command line flags makes sense (makes ours a drop in replacement). Nothing wrong with supporting a token in the source code as well (it would override the command line). As I think about it, I like the idea of simply writing a trivial prescanner that determines what language the user picked. If you find "sub void", it ain't real C, etc. Lots of semicolons means it's not BASIC, etc. > >2. After those, the grammer for an (or many) arbitrary syntax could be >defined. > >3. In all cases, the compiler tools yield a similar internal representation >that is subjected to code generation and optimization. For the original >scripts' syntax, should we generate identical code to the OOpicMK or use our >own? The currently generated code is pretty bad. I'm sure we can do better. > >4. Does the grammer specification require some (or deep) knowledge of the >possible syntactical structures the native byte-codes would permit? If so, >then I should get some more work done. The native bytecodes will tell us what we can and can't do. I see the bytecode map as step #1. ...Andy |
|
From: Neil D. <nd...@us...> - 2004-05-12 02:15:12
|
D. Daniel McGlothin wrote: > > > For the original scripts' syntax, should we generate identical code to > > > the OOpicMK or use our own? > > > > I'm not sure I understand what you mean (it's 2.44am here - brain fade!) > > The point is whether there is two code generators or one. > > One for the project's compiler/code generation; another one (or three) for > the original Savage implementations of C, Basic, and Java syntaxes. > > I'd opt for one only. Asking only for completeness of discussion. I think we'll be able to handle the original Savage C/BASIC/Java syntaxen using a preprocessor like Andy's, which would then output grammar which is compatible with our new compiler. Of course, we should be trying to persuade people to switch to our more complete and standard syntax, but we should also aim to support the Savage "legacy" syntax... :-) > Good night <grin> <Yawn> Good night! Neil -- Neil Durant <nd...@us...> |
|
From: D. D. M. <dd...@mc...> - 2004-05-12 02:04:32
|
> > For the original scripts' syntax, should we generate identical code to > > the OOpicMK or use our own? > > I'm not sure I understand what you mean (it's 2.44am here - brain fade!) The point is whether there is two code generators or one. One for the project's compiler/code generation; another one (or three) for the original Savage implementations of C, Basic, and Java syntaxes. I'd opt for one only. Asking only for completeness of discussion. Good night <grin> Daniel |
|
From: Neil D. <nd...@us...> - 2004-05-12 02:01:49
|
My expertise is on the other end - I have written a number of parsers and code to generate internal representations from an input grammar. So it seems our expertise lies in three convenient areas: Andy: Code generation/optimisation Daniel: Reverse-engineering and op-code specialist Me: Parsing of the input language So perhaps we should work out the boundary between the "front end" part of the compiler, ie the language parsing stuff, and the code generation side. If we can come up with a design for the interface between those two modules, and a rough design for the data structures that the parser will generate to pass on for code generation, then we can make a start. Parsers for compilers generally populate a tree structure, where each node represents some semantic aspect of the code. For example one node might represent a "for" loop, and could have properties such as pointers into a symbol table for the counter variable, and links to other nodes representing the test and iteration expression. It would also have a child node representing the block of code to loop over. That child node would have other child nodes representing the code within the block, and so on. I guess we need to work out what structures will be required to generate the code. Off the top of my head, we would need at least: A tree structure for the program itself A symbol table for variables (with type information) I'm sure we'll need a lot more than this, but my brain is begging for sleep!! Andy, can you think what other structures we'll need to start code generation? Neil Andrew Porrett wrote: > Don't know very much about compiler design. Assumed we would do pretty > much what you outlined. I expect my expertise will come into play more > when we get around to code generation and optimization. > > At 01:45 AM 5/12/2004 +0100, Neil Durant wrote: > >Did either have you have any ideas on the overall design of the compiler? > > > > ------------------------------------------------------- > This SF.Net email is sponsored by Sleepycat Software > Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver > higher performing products faster, at low TCO. > http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 > _______________________________________________ > Oopic-compiler-devel mailing list > Oop...@li... > https://lists.sourceforge.net/lists/listinfo/oopic-compiler-devel > -- Neil Durant <nd...@us...> |
