[project] MSX (Z80) Pascal compiler

[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.

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. 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.

[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: