[project] MSX (Z80) Pascal compiler

[Ñuño Martínez]

I don't know if there's any MSX owner here, but I decided to write a MSX Pascal compiler. That's why:

After finish a fair stable game library (Allegro.pas (http://allegro-pas.sourceforge.net/), test it if you didn't! :wink:) I decided to step back to my origins: the good old MSX system. I almost forget everything about Z80 microprocessor and the MSX hardware, so I looked for information and I found some C and Pascal compilers for Z80 (Did you know there were a Turbo Pascal for MSX? Me didn't!), but that compilers where discontinued, closed and/or non-free.

So here I am with this new bizarre idea. :roll: The objective for version 1.0 is to build a compiler for simple Pascal programs, non Object Pascal, non optimized code, etc. I think I can do it because “simple Pascal” isn't too complex to parse, is it? I never did a compiler before but I did a small script interpretor and a complete math analyzer some time ago. And that wasn't so hard as it seems. :)

I wrote a brief description about what I want to do. If somebody else has interest or is curious about this project (retro game lovers, where are you? :mrgreen:), I'll answer your questions. Any comment and suggestion will be welcome too.

[VilleK]

I don't have a MSX but I used to own a ZX-Spectrum which was a great little Z80-based computer. And I think all retro-projects like yours are really cool, so I say go for it! :)

[WILL]

You might want to check out 'Let's Build a Compiler' (http://compilers.iecc.com/crenshaw/) by Jack Crenshaw. I found it easy to follow and all the code is in Pascal (uses Turbo Pascal dialect for all the code examples and is 100% compatible in FPC with little or no exceptions needed)

[paul_nicholls]

You might want to check out 'Let's Build a Compiler' (http://compilers.iecc.com/crenshaw/) by Jack Crenshaw. I found it easy to follow and all the code is in Pascal (uses Turbo Pascal dialect for all the code examples and is 100% compatible in FPC with little or no exceptions needed)

LOL! You beat me to that...I was going to post that link myself as I have used it to make a scripting language 'compiler' before in the past :)

I second that recommendation ;-)

cheers,
Paul

[Ñuño Martínez]

Thanks for your comments

You might want to check out 'Let's Build a Compiler' (http://compilers.iecc.com/crenshaw/) by Jack Crenshaw...
I did read it some time ago. I'll keep a copy as reference for some tasks but I'll try an object oriented approach.

Now, I decided to do the compiler more generic, so it can be used with other Z80 based devices (i.e. ZX-Spectrum and several 8bit game devices). I think I'll start coding it this night.

[Ñuño Martínez]

SourceForge did accept the project, so if you have interest about it, visit it's project page (https://sourceforge.net/projects/z80-pascal/) and add the RSS feed to your RSS reader.

[pstudio]

Good luck with the project.

I don't know if you're aware of this (http://www.musikwissenschaft.uni-mainz.de/~ag/tply/) website, but it has a Pascal version of Lex and Yacc which you may find useful.

[Ñuño Martínez]

Thanks for the reply, pstudio. I did use Yacc some years ago and I don't like it. I know it's a great application and Free Pascal is written using it, but I don't understand most of its logic and I can't see how to write a compiler using it. I like recursive parsers as Creenshaw suggest in his articles.

[VilleK]

Coco/R saves time when writing recursive parsers. It works with a definition file just like yacc/lex, but with the great benefit that the generated code is readable and easy to debug.

http://tetzel.com/cocor/coco-r-for-delphi/

[Ñuño Martínez]

I'll study it. Thank you, VilleK.

[jdarling]

It would be really cool if you could abstract out the code generator that way the compiler could be ported to other micros as well. I know I started working on a pascal compiler for the AVR family of micros, but quickly ran out of time to work on it. It would have been much easier if I had a pre-developed compiler I could have simply switched out the generator on :)

Maybe just generating Assembly files would be sufficient and let one of the native assemblers take it from there.

[Ñuño Martínez]

I was working on the project and now I have a very simple source editor and a valid scanner. You can get it from the project's subversion (https://sourceforge.net/svn/?group_id=250984).

I've deleted the "label" and GOTO statements from the language because I think they're unnecessary. What do you think about it? Should I restore the GOTO statement?

About the scanner, I have some problems with the BNF description (https://z80-pascal.svn.sourceforge.net/svnroot/z80-pascal/src/compiler/pascal.atg). Coco/R returns some errors I can't understand. They are "deletable symbols" but I can't figure out why they're deletable. These "deletable symbols" result in several LL(1) errors because some symbols are "the start & successor of a deletable structure". Anyway, the scanner and the parser seems to work fine but I'm not sure since the compiler doesn't generate code yet.

I think I'll can fix this once I read again the Coco/R documentation, but if somebody has experience with this kind of tools and he/she has an idea bout what's wrong it will help me a lot.


It would be really cool if you could abstract out the code generator that way the compiler could be ported to other micros as well. I know I started working on a pascal compiler for the AVR family of micros, but quickly ran out of time to work on it. It would have been much easier if I had a pre-developed compiler I could have simply switched out the generator on :)

Maybe just generating Assembly files would be sufficient and let one of the native assemblers take it from there. May be but I can't promise it. Anyway, since Z80 Pascal is open source and free you can modify it as you wish. ;)

[pstudio]

I've deleted the "label" and GOTO statements from the language because I think they're unnecessary. What do you think about it? Should I restore the GOTO statement?
Though I probably wouldn't use it myself, I think you should keep GOTO and labels in the language. It's a part of the language, and some may expect it.

[jdarling]

My two cents are the Label and GOTO are bad carry-overs from Basic into Pascal. I'd remove them as well.

I'll take a look at the projects source, should be interesting to compare to the implementation I started. If it would help I can post up the code I had. I know I had the Lexer, Classifier, and partial Validator complete before I put it "on the back burner".

I had abstracted out each part so I could test and use it for anything else if the need came :). Then again, the way I was designing mine was that for each device you would have an assembly file that would be used for the final output generation. Hard to explain but fun to work on LOL

[Ñuño Martínez]

I agree with jdarling (obviously :roll: ) so there are 2 votes against GOTO and 1 vote to restore it. It may change in the future.

I started to create an "Encoder". But I've find a problem. The parser and the scanner were created using Coco/R and this application generates old Turbo Pascal code without classes and objects, both parser and scanner uses a bunch of global variables to store the current status of the compilation. The problem comes with the "USES" clause. May be creating a way to save all these global variables, restart the compilation with the new UNIT and when that compilation finishes restore the old status and continue. Anyway I don't worry if version 1.0 doesn't support multiple units and the default library would be hard-coded in some way.

I tell this to you if somebody is interested. May be I should use Sourceforge's news as blog or create one. :wink:

[arthurprs]

i vote to keep goto, it's not recomended but sometimes you NEED it
ex: breaking nested loops, or in special "Continue;"

[VilleK]

I also get the "deletable symbol" warning with Coco but the generated code works anyway. How do you mean that it does not generate OOP-code? The generated code are classes that inherits from TCocoRScanner TCocoRGrammar. I believe there are two different versions of Coco for Delphi, have you looked at both of them?

[paul_nicholls]

I also vote to keep GOTO.

Ok, it can very easily lead to 'spaghetti-code', but on the other hand, if used properly it can lead to shorter, cleaner code when breaking out of complex loops, etc.

just my 2c :)
cheers,
Paul

[Ñuño Martínez]

i vote to keep goto, it's not recomended but sometimes you NEED it
ex: breaking nested loops, or in special "Continue;"


I also vote to keep GOTO.

Ok, it can very easily lead to 'spaghetti-code', but on the other hand, if used properly it can lead to shorter, cleaner code when breaking out of complex loops, etc. 3 : 2 then ;)


I also get the "deletable symbol" warning with Coco but the generated code works anyway. How do you mean that it does not generate OOP-code? The generated code are classes that inherits from TCocoRScanner TCocoRGrammar. I believe there are two different versions of Coco for Delphi, have you looked at both of them? I'm not using Coco/R for Delphi, I'm using Coco/R for Turbo Pascal compiled by Free Pascal instead downloaded from ftp://ftp.ssw.uni-linz.ac.at:/pub/Coco/Pascal/ .

I did used Coco/R for Delphi with Wine (Haven't Windows installed) and I don't understand how it works. I tried but I can't. I'm more comfortable with console-based tools for this kind of work. :)

If somebody tells me how to compile Coco/R for Delphi using Free Pascal then I'll try again.

[WILL]

Whatever you do, just be sure to specify it in documentation. :) Otherwise you'll have a lot of confused programmers out there trying to use your stuff. :lol:

[VilleK]

An earlier version of Coco Delphi had a IDE but I only use the command line version of the tool. Here are the sources, they probably have a couple of windows-dependencies though:

http://www.tetzel.com/Coco-R/CocoRDelphiSource.zip

Running CocoDelphi.exe on a command-line using Wine should work great. But if you already made a lot of progress using Pascal Coco then it will probably be quite a bit of work to switch now.

[Ñuño Martínez]

Thanks for the link, VilleK, but I can't compile it with Free Pascal. There's a conflict between Free Pascal's CRC unit (used to generate console programs) and the Coco/R's CRC unit.

By the way, I've find a compiled version I can use with WineHQ at the same webpage. I'll study it.

[Ñuño Martínez]

After read a lot of documentation, make a lot of tests and configure my new computer, today I've released the version 0.0 (https://sourceforge.net/project/showfiles.php?group_id=250984). It's far to be an usable compiler but it works. 8)

Finally I didn't use Coco/R. I tested it and I don't feel comfortable with it. I'm using Crenshaw's articles as guide but I'm trying an object-oriented approach.

Feel free to post your comments here. ;D