User avatar
DavidS
Posts: 3275
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

A Extended Pascal Implementation : CONCEPT.

Wed Apr 11, 2018 10:25 pm

Was looking at BASIC, though had forgoten about Pascal, Pascal is a much better option.

The Concept : in brief:
The goal is a simple Pascal compiler that is easy to use, with an integrated IDE, specifically targeting ARMv5/ARMv6/ARMv7/ARMv8 CPU's, and with extras specific to the Raspberry Pi.

In addition to the normal stuff, the compiler will also include units for GPIO, and creation and management of GUI objects in a very simple way. Further it will have the ability to target Raspberry Pi bare metal, with an extensive set of units to dirrectly play with the hardware on the bare metal level.

The goal is a compiler that simplifies life for newer programmers (as well as the rest of us), is capable of targetting as many Raspberry Pi Operating Systems as possible (including Linux and RISC OS), is useful for OS development and other bare metal applications, is open source (MIT licensed), and provides all units under a very permisive license (MIT license), thus reducing the restrictions on use in comercial products.

It is possible that I may decide to make the units even more permisive in there license, and go with unlicense for there license, still debating on that.


Pascal Reserved Words and builtins to Support : LIST:

Code: Select all

abs                absolute           and
arctan             array              asm
begin              boolean            break
case               char               const
continue           cos                div
do                 downto             else
end                eof                eoln
exp                false              file
for                function           goto
if                 implementation     in
inline             input              integer
interface          mod                nil
not                object             odd
of                 on                 operator
or                 output             pchar
pred               procedure          program
read               readln             real
record             repeat             reset
rewrite            round              set
shl                shr                sin
sqr                sqrt               string
succ               text               then
to                 true               type
unit               until              uses
var                while              with
write              writeln            xor
Extra Units : in brief:

Code: Select all

GPIO  : I have not yet defined the exact functionality.
        though both for OS targets and bare metal.
GUI   : Provides window menu and widget creation and
        management, in the style similar to that done
        by Amiga BASIC or Macintosh QuickBASIC.
BARE  : Provides some extra stuff for baremetal, such 
        as mailboxes, cache management, etc.
THREAD : Multiprocessing releated additions.
of course there will also be all of the normal pascal units, or at least most of them.

AND I HAVE STARTED to play:
This bit of fun project I have already began working towards, getting the tokenizer and parser started this afternoon. I hope to be able to share something of a starting point soon.
Save power, use fewer cycles total. Assembly Language forever :) .

hippy
Posts: 3924
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: A Extended Pascal Implementation : CONCEPT.

Wed Apr 11, 2018 10:44 pm

It might be worth taking a look at Ultibo which is pretty much 'Pascal for bare metal' on a Pi -

www.ultibo.org

User avatar
DavidS
Posts: 3275
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: A Extended Pascal Implementation : CONCEPT.

Thu Apr 12, 2018 1:34 am

hippy wrote:
Wed Apr 11, 2018 10:44 pm
It might be worth taking a look at Ultibo which is pretty much 'Pascal for bare metal' on a Pi -

www.ultibo.org
Have looked at Ultibo, more of an OS than what I am going for. I am just going for a very simple system, that does not rely on anything as closed source as FreePascal, going for much simpler, more fun, and more open.

I like the concept behind Ultibo, and played with it a little a couple years ago when it first apeared (was that mid 2016?) . Though different goals completely, Ultibo attempts to only target bare metal, and provide all of the functionality of an operating system.

My goal is just a simple compiler that targets multiple ARM based OS's on the RPi, as well as being easily usable for bare metal.

Thank you though.
Save power, use fewer cycles total. Assembly Language forever :) .

User avatar
Gavinmc42
Posts: 2138
Joined: Wed Aug 28, 2013 3:31 am

Re: A Extended Pascal Implementation : CONCEPT.

Thu Apr 12, 2018 2:18 am

Welcome back David.
Have fun reinventing the wheel :lol:
that does not rely on anything as closed source as FreePascal,
I thought FPC was Open Source.

I can see a future for Ultibo, going back upstream to mainstream Laz/FPC but also rolling up the Embedded FPC for ARM Cortex micros.
A Pascal for everything.
A MicroPascal version would be nice, ditto a better script version.

Adafruit have grabbed Micopython and rolled a version called CircuitPython.
It is fun to use on the Trinket M0's, easy entry to coding,
Pi Zero's need something like that as they are even cheaper :D

I have been using Ultibo now for two years and still have lots to learn.
It keeps getting better at a rate I can just about keep up with ;)

If you really want to go deep, the trend is 64bit ARMs with lots of extra GPU/NN/ML/CV/CL parallel cores.
A simple language that can handle all those cores is really going to be needed.
Single cores are up against Moore's Law and those extra GPU cores are going to be simple things.

I have looked at Go and Rust, but then Ultibo came out, nearly as good, but much better for embedded.
Perhaps a refined version of Pascal. Look at New Pascal, Smart Pascal, Module2, Oberon and pinch stuff from Go/Rust.
Then throw away most of it.
I really do not want to use C on those GPU's, they deserve something better.
Something that compiles quick too ;)

Another trend is IoT, is Linux/C the best tool/OS for that?
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

User avatar
DavidS
Posts: 3275
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: A Extended Pascal Implementation : CONCEPT.

Thu Apr 12, 2018 3:26 am

@Gavinmc42:
You always give interesting perspectives.

On FreePascal and Open Source:
The compiler is under the restrictive GPL, while open source still a bit more restrictive than should be.
Most units are under a modified version of the LGPL that provides to many restrictions.
These are often refered to as copyleft licenses by open source purests, and are a bit to restrictive for some people (myself included).

On Ultibo:
A very good implementation of a minimalist operating system that attempts to do everything for the user. Not so much working on bare metal as working in the Operating system of Ultibo, which has more functionality than many desktop OS's.

It is a good means of implementing many applications in an environment that does not have to much overhead, and it is better for some applications than a more complex OS would be, though it is already more complex than DOS + GEM, about comparable in complexity to something like MiNT + fVDI + XaAES + drivers (eg modern Atari MiNT with GEM AKA MultiTOS), which is a fairly mature unix like OS.

I see a great future for Ultibo, though I see it becoming a light weight full blown OS, which it nearly is already.

On Pascal for Embeded Applications:
Now this is one application that the compiler I am now (4 hours now) working on could be applied, or any other reasonable Pascal Compiler. The nice thing about Pascal is the the implementations are very uniform, so it is easy to compile code from one with another, often without any changes to the code at all (unless it is target specific code).

I would love to see many bare metal projects written in Pascal.

On multi core applications:
Using pascal to take advantage of multiple core systems is something I have always fits, and a lot better than C and C derived languages in my mind (a descusion that many others have had).

As to targeting other CPU's, GPU's, etc, well that may be a future thing to look at, though for now I am just having some fun, playing around with the goal of poping out a very simple very open Pascal compiler that targets the Raspberry Pi, and at first targets Bare Metal, Linux, and RISC OS for its target environments on the Raspberry Pi.

And yes I will be targetting the ability to take advantage of multiple ARM cores in all the target environments.

On Refined Pascal:
I do not know your definition of refined, though Oberon, New Pascal, etc are very much the opisite in my mind.

A refined Pascal implementation would be simpler, and more complete. Really for the base language this has been done ever since Apple introduced Object Pascal, that is the ultimate level of refinement for Pascal. The implementation of Object Pascal in Turbo Pascal 5.5 is the best known, and the inspiration of the Pascal implementation I am working on.

Now as far as units to include as standard, that has changed in need a lot since, as things have evolved quite a bit. I feel that there are some units needed that were not needed back then, as mentioned in the head post of this thread.

I also think that more extensive typecasting support is needed. The strong typing of Pascal can be a very good thing, though there are times it is needed to treat the same data as if different types.

On IoT:
Nothing new (other than now calling it IoT). The concept of networking small devices, appliences, control sytems, etc has been around for a long time. While I see it as a good thing so long as only with a local area network, that is sepperated from any external connections, I do not like it being connected to the Internet.

As to the question of Linux for that application, ABSOLUTELY NOT the best solution. While Linux is a way to accomplish the goal, it is not going to be as power effecient as a dedicated bare metal application that only turns on the parts of the board that are being used at the time, and is able to put the CPU to sleep for minutes at a time only to be woke up by a timer, or external event, and able to turn off the GPU when not needed, as well as dissabling cache that is not in use, etc.

I Target ARM because it makes since
The ARM is the most widely used CPU on earth today, for a wide veriety of things. Also the ARM is very simple and eloquent, it would be nothing to see a 32 core ARM device in the near future do to the simplicity of the ARM and the small amount of silicon realistate it takes.

Do to the two facts above, and the fact that the ARM is power effecient by nature:
I feel that the ARM is the target to focus on at this time. The ARM has the potential to displace all other offerings. Not to mention how many diferent companies produce ARM based SoC's?
Save power, use fewer cycles total. Assembly Language forever :) .

User avatar
Gavinmc42
Posts: 2138
Joined: Wed Aug 28, 2013 3:31 am

Re: A Extended Pascal Implementation : CONCEPT.

Thu Apr 12, 2018 4:44 am

Yep, understand a bit more where you are coming from now

I wish there was just pure ARM64, throw away ARM32 and Thumb support etc.
Building the future, we don't need boat anchor legacy support, that's for the Linux guys :lol:

Sakaki has done a great job bringing Aarch64 alive on the Pi.
viewtopic.php?f=63&t=208314&start=75
If the new Lan/WiFi gets working soon it may end up as my Pi3B+ development box.
Finally I can toss the Intel Celeron Core Duo Linux box or save it for games ;)
Hmm, wonder how Warzone2100 plays on the new 3B+ ;)

ARM will be around for a few more decade unless RISC V gets more momentum.
According to ARM, Aarch64 should run faster and the core uses less power in 64 bit mode.
64bit is more power efficient? Pi3B+ will use less power or get less hot, that is win, win to me?

I don't really understand the insides of languages, I just use them, since the Pi came out I have learned and used lots.
Whatever works the best gets used, currently for the single purpose application stuff I do, it is Ultibo.
The advantage I see with Ultibo is it uses Free Pascal which is well developed and supported.
It has way more stuff than I really need, but that it good, I can learn it as I use it.

Ideally I am told, BSD license would be better than GPL, but that for the lawyers, lucky I don't do commercial work :lol:
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

jahboater
Posts: 3067
Joined: Wed Feb 04, 2015 6:38 pm

Re: A Extended Pascal Implementation : CONCEPT.

Thu Apr 12, 2018 6:52 am

DavidS wrote:
Wed Apr 11, 2018 10:25 pm
The goal is a simple Pascal compiler that is easy to use, with an integrated IDE, specifically targeting ARMv5/ARMv6/ARMv7/ARMv8 CPU's, and with extras specific to the Raspberry Pi.
If you want to write compilers, have you looked at bison (and I suppose flex) ??
They are the replacements for yacc (Yet Another Compiler Compiler!!) and lex.

User avatar
Gavinmc42
Posts: 2138
Joined: Wed Aug 28, 2013 3:31 am

Re: A Extended Pascal Implementation : CONCEPT.

Thu Apr 12, 2018 7:27 am

Bison?
https://gnuu.org/2009/09/18/writing-you ... -compiler/
Cool, uses LLVM, make a toy Pascal compiler for the QPU's ;)
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

jahboater
Posts: 3067
Joined: Wed Feb 04, 2015 6:38 pm

Re: A Extended Pascal Implementation : CONCEPT.

Thu Apr 12, 2018 8:11 am

My experience from many many years ago was that it quite easy to write a lexical analyzer that is smaller and faster than lex can produce (but the lex source is easier to change and more readable). Yacc on the other hand does a brilliant job - the parser it produces is small and very fast. Most importantly if you want to change the language syntax, it is trivially quick with yacc (a very simple edit), but would require complex code changes in a hand written parser.
I think bison can deal with a wider range of grammars than yacc could.

The analyzers/parsers produced may be compiled with any C compiler, it doesn't have to be LLVM.

User avatar
DavidS
Posts: 3275
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: A Extended Pascal Implementation : CONCEPT.

Thu Apr 12, 2018 1:34 pm

I have never been one for Bison, Lex, yacc, etc. I prefer to hand code the lexer in the target language to create a self hosting compiler.

If you give some thought to the implementation of your code it is pretty simple to make it possible to change the grammar to be compiled. It is just a matter of giving a little thought to how it can be changed while implementing it.

There are many different ways to accomplish a given goal. I will not say that mine is the best, though it does the job.

Also I feel that a compiler should be able to compile it self with only the minimal tools needed for the compiler to compile any other application.

That is the only tools needed to create a compiler should be the compiler being created, a text editor, an assembler. Bootstrap by hand ideally. In the world of MS-DOS/PC-DOS/DR-DOS/FreeDOS it has been seen for the only tools used to be the command interpreter (command.com) and debug to bootstrap a compiler.
Save power, use fewer cycles total. Assembly Language forever :) .

jahboater
Posts: 3067
Joined: Wed Feb 04, 2015 6:38 pm

Re: A Extended Pascal Implementation : CONCEPT.

Thu Apr 12, 2018 4:59 pm

I prefer to hand code the lexer in the target language to create a self hosting compiler.
Yes, I too would write the lex part by hand, but not the main grammar.
Lex seems to produce huge code.

Here is a yacc grammar for the C language:

https://www.lysator.liu.se/c/ANSI-C-grammar-y.html

I couldn't write a parser for C as simple, clear, and easy to change as that!
Each to their own though, good luck!

GCC uses yacc by the way and it is self hosting.

User avatar
DavidS
Posts: 3275
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: A Extended Pascal Implementation : CONCEPT.

Thu Apr 12, 2018 8:24 pm

Well it is interesting, as my parser is already changing. Like I said this is fun and play.

I decided to take a bit of a middle road to start with, a bit BASIC like and a bit Pascal like. It is still likely to end up also doing some later modification to make a Pascal version. Though to do Pascal without as much restriction on declarations, no semicolons, and no begin end, just blocks composed by there end statements (more BASIC like), or is it BASIC with more Pascal like features (such as records), the two languages have so much in common that it could be viewed either way.

In some ways it is more BASIC, in others it is more Pascal.

Definitely it will support variable typing by suffix as well as by declaration (so both languages methods).
Save power, use fewer cycles total. Assembly Language forever :) .

User avatar
Paeryn
Posts: 2173
Joined: Wed Nov 23, 2011 1:10 am
Location: Sheffield, England

Re: A Extended Pascal Implementation : CONCEPT.

Thu Apr 12, 2018 10:52 pm

Having the parser created by bison/yacc is a big boon as the BNF source gives the user a formal description of the language which the parser is actually generated from. You don't have to worry about keeping the two in sync.

Yacc only handles LALR(1) grammars I think so you have to be careful with ambiguous grammars. Bison can handle LALR(1) and GLR grammars.

jahboater:
I thought GCC used to use bison but switched to a hand-written parser (at least for C and C++) some years ago.
She who travels light — forgot something.

User avatar
DavidS
Posts: 3275
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: A Extended Pascal Implementation : CONCEPT.

Fri Apr 13, 2018 9:05 am

Well I have been playing with the implementation of my very simple parser, just to see that it is going to be as modifiable as I want. Still a few modifications needed before I formalize the implementation, though it is looking good so far.

The primary goal is a simple recursive decent implementation, that keeps tract of variable usage even between expressions to minimize the redundant writing out and reading in of values, preferring to keep values in registers as much as possible while they are being operated on. As well as making it a simple matter to change the syntax and grammar of the language (to the point of being able to use nearly unmodified code to move between languages).

A secondary goal, that also is going well, is to have it structured in a way that switching over to a tree based parser in the future will be fairly simple, using only a minimum of modification. Most feel that adding optimization support is simpler with a tree based compiler (though as said this compiler is NOT going to optimize at all).

This compiler is not going to be optimizing at all. To keep things simple the target for version 0.00.01 is simply to support a decent subset of Pascal, be able to compile it self, and have the basics of a system and crt unit implemented, minimally targeting RISC OS (Linux and Bare Metal are for once it is reasonably complete). For version 0.00.02 it would be nice to also have a minimal BASIC compiler, bringing the same compiler code base up to two languages. From there i will be finishing out the Pascal compiler and units, as well as keeping the level of functionality of the BASIC compiler just one step behind the Pascal version.

Currently I am thinking that I may add a C version at about version 0.01.00, so only 100 revisions to go before that. Though I likely will not put nearly as much effort into keeping up with the C version simply because there are already so many C compilers, that are actively maintained.

As an irony: I am writing the compiler in Pascal on RISC OS without any existing Pascal Compiler. As such to bootstrap it I am hand translating my Pascal Code to ARM BASIC V in order to test it and bootstrap the real thing.
Save power, use fewer cycles total. Assembly Language forever :) .

User avatar
DavidS
Posts: 3275
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: A Extended Pascal Implementation : CONCEPT.

Fri Apr 13, 2018 4:12 pm

It is looking like I may get far enough to begin sharing soon. I am quickly getting the tokenizer/lexer to a usable point, and working on defining the language within the form I chose to implement them. The language definition to start with is just a subset of Pascal, with a little loser rules about typing, just needs to compile itself for the first version.
Save power, use fewer cycles total. Assembly Language forever :) .

StevoD
Posts: 20
Joined: Tue Aug 29, 2017 11:37 am

Re: A Extended Pascal Implementation : CONCEPT.

Mon Apr 16, 2018 10:55 am

This might help you get your pascal bare metal setup going https://github.com/mvdhoning/fprpbm

I saw it while looking at the opengl stuff from the same person which should work with ultibo now.

D./

User avatar
DavidS
Posts: 3275
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: A Extended Pascal Implementation : CONCEPT.

Mon Apr 16, 2018 7:47 pm

StevoD wrote:
Mon Apr 16, 2018 10:55 am
This might help you get your pascal bare metal setup going https://github.com/mvdhoning/fprpbm

I saw it while looking at the opengl stuff from the same person which should work with ultibo now.

D./
No interest in using FreePascal or attempting to write a compiler that can deal with the very odd anit-modern extensions there of. Though I do thank you for the pointer. My playing in assembly on the RPi in baremetal is the basis of the Baremetal target.
Save power, use fewer cycles total. Assembly Language forever :) .

ejolson
Posts: 2049
Joined: Tue Mar 18, 2014 11:47 am

Re: A Extended Pascal Implementation : CONCEPT.

Tue Apr 17, 2018 12:29 am

DavidS wrote:
Fri Apr 13, 2018 9:05 am
As an irony: I am writing the compiler in Pascal on RISC OS without any existing Pascal Compiler. As such to bootstrap it I am hand translating my Pascal Code to ARM BASIC V in order to test it and bootstrap the real thing.
It would be quicker to not bootstrap it: there is no need for a compiler to compile itself, especially when the compiler itself doesn't optimize. I think the original Turbo Pascal for the Z80 and later the 8086 was written in assembler. For the present project, it might be better to use C rather than Basic V.

User avatar
DavidS
Posts: 3275
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: A Extended Pascal Implementation : CONCEPT.

Thu Apr 19, 2018 2:11 am

ejolson wrote:
Tue Apr 17, 2018 12:29 am
DavidS wrote:
Fri Apr 13, 2018 9:05 am
As an irony: I am writing the compiler in Pascal on RISC OS without any existing Pascal Compiler. As such to bootstrap it I am hand translating my Pascal Code to ARM BASIC V in order to test it and bootstrap the real thing.
It would be quicker to not bootstrap it: there is no need for a compiler to compile itself, especially when the compiler itself doesn't optimize. I think the original Turbo Pascal for the Z80 and later the 8086 was written in assembler. For the present project, it might be better to use C rather than Basic V.
I have actually began redoing parts of it in ARM Assembly. I have decided to forgo the bootstrap process and just write the compiler in the final implementation language, which shall be ARM Assembly as it is only intended to be hosted on the ARM CPU, and only to target the ARM CPU.

Though I have also began implementing a very similar Pascal Compiler in 65816 Assembly targeting GS/OS. This is a parallel project, very much just for fun (I do not expect a new IIGS GS/OS based compiler to get much of an audience).

As far as C is concerned, I am a strong believer that compilers should be written in the language they host, Assembly Language, or machine language, though never in a different high level language. This is just me, I know I am different than most.
Save power, use fewer cycles total. Assembly Language forever :) .

Heater
Posts: 10021
Joined: Tue Jul 17, 2012 3:02 pm

Re: A Extended Pascal Implementation : CONCEPT.

Thu Apr 19, 2018 8:39 am

DavidS,
As far as C is concerned, I am a strong believer that compilers should be written in the language they host, Assembly Language, or machine language, though never in a different high level language.
I used to feel the same way. Any "real language", call it "realang", should be compiled in machine code by a realang compiler and the realang compiler should be written in realang.

As such the only real languages for me were things like C, C++, Pascal, Ada, Algol...

Now a days, whist I think self compilation is essential for things like C, I'm not so fussy. For a number of reasons.

Languages like Python and Javascript are real enough, they get useful work done, they make many tasks much easier, they are cross platform and available on many platforms, including micro-controllers. But I see no reason why a Python or Javascript engine should be written in Python and Javascript respectively. C and C++ are available everywhere so it makes sense to create Python, JS, whatever compilers/run times in C, C++.

I have been playing with an extreme case recently, Scala. Now the Scala compiler is actually written in Scala but presumably it was originally developed in Java. Scala generates byte codes for the Java virtual machine. But it gets complicated, I'm using Scala with the SpinalHDL hardware description language library, as such my scala ends up producing a hardware description for FPGA in Verilog or VHDL. Not only that but I can write test benches for that hardware that end up producing C++ , from the Verilog, which is a simulation of the design that can be run on the PC.

It's all very meta. Far away from my old ideas of "real languages".

Besides, in my one and only attempt to define a simple language and build a compiler for it I failed to get as far as having it bootstrap itself. I was amazed I had managed to get it to generate binaries for x86 and Parallax Propeller MCU :)

hippy
Posts: 3924
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: A Extended Pascal Implementation : CONCEPT.

Thu Apr 19, 2018 1:17 pm

DavidS wrote:
Thu Apr 19, 2018 2:11 am
I have actually began redoing parts of it in ARM Assembly. I have decided to forgo the bootstrap process and just write the compiler in the final implementation language, which shall be ARM Assembly as it is only intended to be hosted on the ARM CPU, and only to target the ARM CPU.
I am not sure exactly what you are saying there and what the consequences are, whether this is the process you are currently following or what the final delivery will be, but it seems to me you intend to create a compiler which can only be run on an ARM platform, physical or emulated.

If that is the case it seems unnecessarily limiting, restrictive and inconvenient. It would make cross-compiling from non-ARM platforms difficult and goes against the traditional embedded workflow of compiling on host then transferring to target.

I am wondering if you aren't approaching this with too much of a bottom-up approach without considering things from a top-down perspective.

ejolson
Posts: 2049
Joined: Tue Mar 18, 2014 11:47 am

Re: A Extended Pascal Implementation : CONCEPT.

Fri Apr 20, 2018 12:27 am

hippy wrote:
Thu Apr 19, 2018 1:17 pm
If that is the case it seems unnecessarily limiting, restrictive and inconvenient.
I think Anders Hejlsberg wrote the original Turbo Pascal in assembler because there were no good C compilers targeting the Z80 and he was faced with extreme RAM constraints. In 1983 Turbo Pascal ran on an 8-bit microcomputer with 64KB RAM while real computers such as the DEC VAX and IBM 308x series had as much as 64MB RAM.

In a way the situation today is similar. The Raspberry Pi has 1GB RAM while Xeon and Power9 servers have as much as 1TB RAM. Although there is still a factor of 1000 difference between low-end and high-end computers, a Pascal compiler for the Raspberry Pi need not be written in assembler to work well. Even if writing a compiler in assembler is not that difficult, the possibility of cross compiling is a very strong reason to write any new compiler using an established portable programming language.

jahboater
Posts: 3067
Joined: Wed Feb 04, 2015 6:38 pm

Re: A Extended Pascal Implementation : CONCEPT.

Fri Apr 20, 2018 7:27 am

DavidS wrote:
Thu Apr 19, 2018 2:11 am
As far as C is concerned, I am a strong believer that compilers should be written in the language they host,
Yes, its a good test for the new language. If its not capable of implementing an efficient compiler I probably would not want to use it for real world large scale coding.

hippy
Posts: 3924
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: A Extended Pascal Implementation : CONCEPT.

Fri Apr 20, 2018 12:31 pm

jahboater wrote:
Fri Apr 20, 2018 7:27 am
DavidS wrote:
Thu Apr 19, 2018 2:11 am
As far as C is concerned, I am a strong believer that compilers should be written in the language they host,
Yes, its a good test for the new language. If its not capable of implementing an efficient compiler I probably would not want to use it for real world large scale coding.
A compiler relies on very few of the things a compiler has to support and deliver in the real word so being able to compile itself is not really a useful metric of its capabilities.

There are other advantages for a compiler being able to compile itself but it's not essential. In many cases a compiler compiling itself will deliver something less efficient and robust than a compiler written in another language. Particularly something like C where many man-centuries have likely been invested in its development.

jahboater
Posts: 3067
Joined: Wed Feb 04, 2015 6:38 pm

Re: A Extended Pascal Implementation : CONCEPT.

Fri Apr 20, 2018 12:47 pm

hippy wrote:
Fri Apr 20, 2018 12:31 pm
There are other advantages for a compiler being able to compile itself but it's not essential. In many cases a compiler compiling itself will deliver something less efficient and robust than a compiler written in another language. Particularly something like C where many man-centuries have likely been invested in its development.
Yes indeed.

For interest:
When you install gcc, the build is done twice.
First it compiles itself using the existing compiler on the machine.
Then it does it all again using the new freshly built compiler.
This 1) tests the newly built compiler, and 2) ensures the new compiler is as fast as possible because it is built with the latest code generation.

Return to “Other programming languages”