[fpc-devel] Project Idea: Mini-FPC

[John Clymer]

There is a slightly more "modern" P5 based off of P4, with source code that can 
be compiled using Borland Pascal (and presumably, FPC's Turbo mode should be 
close to compiling it as well.)

http://www.standardpascal.org/p5.html




________________________________
From: Skybuck Flying <skybuck2000 at hotmail.com>
To: FPC developers' list <fpc-devel at lists.freepascal.org>
Sent: Sun, September 11, 2011 12:01:50 AM
Subject: Re: RE : [fpc-devel] Project Idea: Mini-FPC

"
Have a look at the P4 pascal compiler
"

Ok, I had a look at it.

"
http://homepages.cwi.nl/~steven/pascal/ .
"

Nice site.


"
The whole compiler is written in pascal and is only 4000 lines in 1 file.
"

Line-wise not to bad, the code itself also looks not to bad, but it does look:

1. Very old.
2. Written by a C programmer or so or a really old pascal programmer.
3. It doesn't use the case insensitivity future of pascal.
4. It has a huge ammount of q's, p's, kl's and lpt's as variable names just 
illustrate that this code and the variable names are not "self-documenting".
The website/book tries to document these variables but I think I already spotted 
some variables which remained unexplained.

Therefore I do think this code needs a huge ammount of "refactoring" or simply 
put: "renaming of variables".

5. It was also not written in an object orientated way, this will probably mean 
that it's not very extendable and goes against the oo encapsulation philosophy 
and so forth...
So use just pascal only will need lead to name space conflicts within 
units/modules, this could be somewhat diverted by using multiple units/modules 
and perhaps prefixes but it is far from ideal.

6. Ultimately it would be beneficial if a mini-fpc or mini-pascal compiler would 
also include all modern oo features just so I can compile my own sources to 
whatever instruction set. So for this purpose this
code does not really seem that suited ?!?

7. Why is it called an "interpreter" and not simply an "executor" ? Is there a 
technical reason for it ? The word "interpreter" has a bad association in my 
mind... I associate it with a "basic interpreter" which I think parses and 
executes at the same time.
This is not what the interpreter seems to be doing... it's actually executing 
instructions so it's not really an interpreter then is it ?

"It generates a high level pcode and comes with a pcode interpreter (1000 lines 
of pascal in a second file)."

This is nice, though the instruction set still seems a little bit large and a 
little bit weird here and there...

For example what is "SET - Set intersection"  ???

"Simpler you can't get. Cross platform. Only standard pascal though, no
objects, etc.
"

Hmm I don't know if that claim is true about being "simpelst" I doubt that 
actually... There is one more pascal compiler out there which might also be 
pretty good ;)

I find it kinda odd how all the documentation is seperated from the source code 
in an html file... at the same time I also find it somewhat interesting.

This allows the comments/explanations to be read seperatedly from the source... 
but it also requires some back and forth switching to see what it is referring 
to.

Perhaps a second version could be made where code and documentation is 
integrated into each other, this would probably/actually be a better way to keep 
the code usuable.

As it is right now it seems hard to maintain because of all the  q's p's and so 
forth, but perhaps that is fixeable, but then it becomes a question of "is it 
worth it ?"

The answer to that question depends on many other things.

For now it is kinda interesting and I will probably play a little bit with it 
just to see if it will compile in Delphi ;) :)

I have my doubts thought ;) :) but so far I am willing to believe that it will 
compile and run ;) :)

The biggest adventage so far:

1. It's free.

2. It's relatively tiny.

3. It's pretty well documented.

4. It seems to produce "virtual" instructions which could be a big adventage, 
especially if it's possible to modify the instruction set, not sure about that 
though.

5. It seems to have an executor (which executes the instructions).

6. It seems to assume each instruction is the same size, which I kinda like too.

7. It has syntax checking/error reporting.

8. All source is freely available.

9. The book/documentation is freely available (a draft)

10. Because of the "virtual" instructions it could be possible to re-write the 
interpreter in a different language to make the instructions run on different 
platforms so in that sense
it's cross platform like java bytecode (virtual machines running on a "real" 
platform).

The biggest disadventages so far:

1. It's not object oriented, it's not modern, not known if it's possible to 
extend and would require further knowledge and time.

2. It's somewhat badly written, not self-documenting, though this could be fixed 
but this fixing would require some time, and I am not sure if it would make the 
code more readable but I would think so.

3. It's not object orientated which could cause problems, though it could be 
wrapped in objects but would also require more time.

4. Important comments/explanations are not embedded in the source itself, 
perhaps it should and would also require some further time to integrate it.

Conclusion so far:

1. It could be usefull to try and modify it to try and output redcode/corewar 
instructions, that would be cool, then warriors can be written in pascal code ! 
;)

2. It could be usefull to try and write a php interpreter/executor so that the 
pascal p-code/virtual instructions can be run on webservers like 
linux/apache/php/mysql. Programs would be limited to just plain pascal though, 
but could still be somewhat usefull and more easy to debug on for example Delphi 
;) :) (in an algorithmic way... hopefully the compiler/executor don't have any 
bugs itself ??? <- this is a good question and the answer is probably it has 
bugs, most software has bugs, bugs in it would suck, so this could be a hidden 
problem with it ;) :) but perhaps with some help from guys on this mailing list 
it might be fixeable ?!?)

3. It could be usefull to try and expand it so it can compile "cuda" kernels 
written in a pascal like language. (Or perhaps opencl kernels, personally I am 
interested in cuda only though for the time being ;) :))
Here there is also a possible adventage, the compiler could be made "cross 
platform" for cuda and opencl, write a "pascal kernel once" and compile to 
either cuda or opencl intermediate instructions, that in itself would be highly 
interesting, but if it can be done remains to be seen, I'd give it a 90% chance 
of succeeding, though cuda does have some features which opencl does not, but 
90% compatibility would still be nice :)

4. It could also be used for further experimentation to add additional 
instructions or an "interleaved program" which executes between the other 
instructions to collect data/analysis data of how the other program executes, 
which is also interesting.

So this code does have some potential ;) :)

Lastly a comparision with free pascal to mini-fpc "trajectory":

1. The p4 compiler is already very minimal compared to fpc so this will require 
less work.

2. The p4 compiler is already producing "virtual instructions" and does not need 
an entire platform and complex rtl's which will also require less work.

3. I am not sure if the p4 compiler can compile itself, the text claims it 
does... which is kinda interesting... how it does that I don't know yet... it's 
probably not much of an issue because everything is in one file, unlike free 
pascal where a huge ammount of files
and a pretty large ammount of "fpc_" hooks have to be hooked up, perhaps the p4 
compiler is also more clean and doesn't have "self-hosting language features" 
which free pascal does seem to need.

4. There is no assembler code in the p4 compiler which is good/nice.

5. There is no complex binary file format as far as I saw so far... but I could 
be wrong about that... but it's probably not as complex as PE windows format, 
for example...

6. There does not seem to be a complex debugger support, which could be a 
disadventage on the long run, but also an adventage on the short run, less 
complexity because of it.

7. The p4 compiler does seem to support some text, which is kinda nice, but 
ultimately not really required for my purpose I think, but still kinda nice, but 
so does free pascal but probably in a more complex way, and the unicode support 
seems also messy.

8. The free pascal compiler has an enormous mess of types, the types are all 
over the place, they are not located in a single location, but pretty much 
everything, many duplicates, many different names for the same thing.

So at first glance all-in-all it doesn't seem to be bad ;) :) and therefore I 
will have a more closer looksy in the coming days but in the end I would need 
object orientation, so on the long run P4 seems like a dead end ;)

So it depends a bit on if mini-fpc becomes a reality or not, if not then P4 
seems to be a good alternative ;) :)

Bye,
Skybuck. 
_______________________________________________
fpc-devel maillist  -  fpc-devel at lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20110911/549fe4f0/attachment.html>