Hi Compiler developers.

I do lots of software projects for PCs and for embedded devices.

While I do all PC projects (for Windows and Linux) in Object Pascal, which is my favorite programming language as it offers the best productivity and the lowest count on errors that show at runtime, I am forced to use GCC for the embedded projects as the processors used here (usually 68K, PIC and NIOS) are not supported by FPC.

Now I just took a somewhat deeper look at how the new 4.x versions of GCC work and so the question comes up (again) why I can't use FPC for the embedded software tasks.

GCC uses the "preprocessor" and the "parser" to create an intermediate code (RTL: "Generic" or "Gimple"). This process is independent from the target-architecture the code is to be compiled for. Now the RTL is optimized and finally a target specific "code generator" produces the object code which now is combined with other object code by the linker.

AFAIK FPC works quite similar, but while only the "parser" really knows about the programming language, it comes with it's own preprocessor (which is only used optionally), it's own code generator and it's own linker. AFAIK, it even provides it's own "make" to compile multiple files.

I could imagine a system that only provides a Pascal-to-RTL-parser and uses many of the GNU tools (preprocessor <optionally>, optimizer, code generator, linker, make).

This would just provide another language for GCC and for hopefully allow me to use FPC-Pascal for any processor architecture supported by GCC.

Are there other than historical reasons that FPC is this "self-contained" ? (I suppose compiling speed is an issue here, so a "GCC compatible parser" might only be an additional tool provided by the FPC team, but I'd really love to use this for my embedded projects.)

-Michael

Michael Schnell wrote

AFAIK FPC works quite similar, but while only the "parser" really knows about the programming language, it comes with it's own preprocessor (which is only used optionally), it's own code generator and it's own linker. AFAIK, it even provides it's own "make" to compile multiple files.

This last is not correct. it's regular make.

We don't want to depend on the work of other people. Do do what you want would also mean that the RTL depends on libc, and this is totally out of the question.

What you want is done by GPC and p2c.

Michael.

Michael Van Canneyt wrote

Do do what you want would also mean that the RTL depends on libc

The generated code would probably depend on libgcc (for helper routines used by gcc when lowering the intermediate code to machine code), but not necessarily on libc (unless you insert calls to libc functions in your intermediate code).

Jonas

Op Tue, 4 Nov 2008, schreef Michael Schnell:

Are there other than historical reasons that FPC is this "self-contained" ? (I suppose compiling speed is an issue here, so a "GCC compatible parser" might only be an additional tool provided by the FPC team, but I'd really love to use this for my embedded projects.)

Speed is an issue, but not the main reason. Using GCC's backend is difficult, reasons are it is a moving target and because it doesn't necessarily implement the features we need, many of our features, like resourcestring tables, require heavy support from the code generator. Another reason is that GCC is written in C, and the code is hard to understand for an outsider. I prefer coding in Pascal, and I understand the architecture of FPC.

Daniël

This would just provide another language for GCC and for hopefully allow me to use FPC-Pascal for any processor architecture supported by GCC.

Already finding skilled contributors to FPC is hard. If deep C knowledge would be also a requirement it would be even harder and FPC would have gone down the drain already years ago as GPC did.

In our previous episode, Michael Schnell said:

Correct.

Now I just took a somewhat deeper look at how the new 4.x versions of GCC work and so the question comes up (again) why I can't use FPC for the embedded software tasks.

Because you haven't ported FPC to those architectures yet.

GCC uses the "preprocessor" and the "parser" to create an intermediate code (RTL: "Generic" or "Gimple"). This process is independent from the target-architecture the code is to be compiled for

(... in a between coffees first order design sketch... Better check that this also really the case in practice)

It started out on Dos, not Unix, and the early gcc's were pretty unusable. At least I heard Florian say that once (and I can imagine)

Actually, using gcc on windows is still ackward to this day. Keep in mind that you would have to maintain your own ecosystem of all those tools on Windows.

Moreover, gcc is a moving target that goes through a major restructure every few years. Keeping up is a chore. (see the many discussions on the GPC list about moving to newer versions).

While the basic concept parser->IL->binary code remains the same, the border conditions don't. Moreover, adding an additional architecture to such fpc-gcc hybrid might still be a lot work, because of specific things in that architecture that need to be fixed, worked around etc.

(I suppose compiling speed is an issue here, so a "GCC compatible parser" might only be an additional tool provided by the FPC team, but I'd really love to use this for my embedded projects.)

If I had to point a finger, then the handling and supportability is the main reason. If I want to use a compiler, I want to use simply a compiler, not a construction kit with twenty tools ranging from a generator to query my system to a linker.

Michael Schnell wrote

I could imagine a system that only provides a Pascal-to-RTL-parser and uses many of the GNU tools (preprocessor <optionally>, optimizer, code generator, linker, make).

FPC-generated object files can already be integrated with the GNU linker and make. A preprocessor has no place anymore (optional or not) once you have parsed and generated some form of intermediate code. Running a C preprocessor on the initial Pascal code could create quite unexpected errors, since the tokens recognised by the C preprocessor have no special meaning in Pascal and can thus appear anywhere.

As for using the gcc code generators and optimisers: gcc's ability to use gimple as input is quite new (can it actually already do that? afaik it's still a work-in-progress as part of its whole program optimisation infrastructure). Before that, to use the rest of the gcc infrastructure you would have to integrate the gcc backend into your compiler (as gpc has done). That really is an enormous job and requires constant updating every time a new gcc version is released.

Are there other than historical reasons that FPC is this "self- contained" ? (I suppose compiling speed is an issue here, so a "GCC compatible parser" might only be an additional tool provided by the FPC team, but I'd really love to use this for my embedded projects.)

The main reasons are
1) all people working on FPC are primarily Pascal programmers, and hence prefer programming in Pascal
2) a number of FPC's core developers are very averse to external dependencies for various reasons

Jonas

In our previous episode, Michael Van Canneyt said:

I'm not too fond of linking in libc, but IMHO dealing with the whole ecosystem of tools and binaries and emulation layers on major platforms as windows to just make proper releases would be my biggest fear.

Not that I couldn't handle it, but to package it transparantly to users in the hope that it will actually work. GPC never even got to that stage.

What you want is done by GPC and p2c.

Do you suggest they offer the rich Object Pascal language that FPC has ?

-Michael

Op Tue, 4 Nov 2008, schreef Michael Schnell:

> What you want is done by GPC and p2c. > Do you suggest they offer the rich Object Pascal language that FPC has ?

The point is those compilers cannot provide it because of (a) technical limitations, and (b) because their approach makes it harder for them to be successfull enough to get the manpower to implement the rich OP language.

Daniël

Michael Schnell wrote

> What you want is done by GPC and p2c. > Do you suggest they offer the rich Object Pascal language that FPC has ?

Not at all, rather the contrary, as far as I know.

But they do their job as you ask it... That they don't offer all FPC features is of course something that you'll then have to live with...

Michael.

Marco and all others:

Thanks,
all points taken,
another dream down the drain :(.

So the only future option I am still intending to take one day is doing a NIOS code generator for FPC.

Though since some time there is a concurrent concept: you now can buy (!) a CLR (they say ".NET") - framework for the NIOS. Using Oxygen/Prism there might be a reasonable path to port Delphi software to the embedded device. Still quite far-fetched as well, but sounds interesting.

-Michael

The point is those compilers cannot provide it because of (a) technical limitations,

I don't think this is true. GCC can compile Java which I think is an object language in a similar extend as Object pascal is. And it seems to be similarly "rich", though of course in different directions.

-Michael

Michael Schnell wrote

Thanks, all points taken, another dream down the drain :(.

I am personally (every now and then) working on an FPC backend that emits llvm code. Llvm has been designed from the ground up to take some form of intermediate code as input and as a generic backend for other compilers. It's still quite young as a project and does not yet support as many targets as gcc, but it is evolving and improving very quickly.

See http://llvm.org for more info.

Jonas

But they do their job as you ask it...

The job I am asking for is porting Delphi software to different CPU architectures. If the tool level is not as high as FPC can provide, I can redo the code in C as just as well.

-Michael

In our previous episode, Michael Schnell said:

> What you want is done by GPC and p2c. > Do you suggest they offer the rich Object Pascal language that FPC has ?

How much do you need on a PIC ?

llvm is interresting to say the least. I experimented with it a bit but never got to do anything serious.

A llvm backend is surely doable especially if you can get an AST out of FPC.

Op Tue, 4 Nov 2008, schreef Michael Schnell:

While I do not deny this, I want to say is that our code generator has a lot of support for Object Pascal specific features that are for certain not available inside the GCC backend. This includes resourcestring, but also Pascal objects/classes, interfaces and more.

It might be possible to work around it (after all GCC is Turing complete so any program should be implementable on the backend in theory), it would never become the same quality implementation that we have now.

Daniël

Sounds very interesting indeed ! Please keep me informed on what you come up with on that behalf !

NIOS is a very simple load-store 32 Bit RISK architecture, similar to the initial ARM Core, so I suppose it would be quite easy to port the ARM code generator of llvm to NIOS.

But OTOH I feel a bit uncomfortable to see yet another intermediate code (after GCC's "RTL", CLR's (.Net/Mono) "CIL" and FPC's own stuff) in the game.

-Michael

How much do you need on a PIC ?

I did not have many hope for really using Pascal on the PIC, but I am just thinking about a project with a PIC24 (which is a quite normal 16 bit processor core with 64K linear addressable memory (completely integrated in the chip), other than the PIC16, which is an 8 Bit processor with no "memory" bit only "Registers" in multiple 256 Byte banks).

Here I in fact need to port part of an existing Delphi project (a master node of a serial communication network).

-Michael

Michael Schnell wrote

I did not have many hope for really using Pascal on the PIC

If you google for: pic pascal compiler

There are plenty of options.

I am using mikroPascal, and it's an excelent choice:

http://www.dontronics-shop.com/mikroelektronika-pascal-compiler-for-pic.html

Similarly there are lot's of Pascal compilers for other embedded platforms.

In our previous episode, Michael Schnell said:

Yes, but most come with only 8k :-) Only recent roadmaps seem to finally have some with more memory.

Well, I gave up PIC24 since they don't contain motorcontrol, so I'm now using their big brother dspic33 (the 100 pin variants). Though apparantly that is now a new architecture, because since a few weeks, both have an own compiler.

,other than the PIC16, which is an 8 Bit processor with no "memory" bit only "Registers" in multiple 256 Byte banks).

I never used those, but their brother, the PIC18, which is roughly the same with some additional regs to make a compiler workable. Still a 256 byte page though.

Here I in fact need to port part of an existing Delphi project (a master node of a serial communication network).

But serial access in both is on the level "put a byte in a register, and wait for a bit to be set", not componentized like e.g. cport or async. The overhead would kill you.

Marco van de Voort wrote

Well, I gave up PIC24 since they don't contain motorcontrol,

I've always wanted to know what does a microcontroller with motorcontrol is supposed to do different from a normal microcontroler?

I mean, to drive a stepper motor, for example, you just need 4 or 5 output pins from any microcontroller and a darlington driver to deacoplate and power up.

Michael Schnell wrote

But OTOH I feel a bit uncomfortable to see yet another intermediate code (after GCC's "RTL", CLR's (.Net/Mono) "CIL" and FPC's own stuff) in the game.

GCC's RTL and FPC's node tree representation were never designed as a generic intermediate layer that you can target from any other compiler. GCC's RTL also has too little high level information to be useful when performing whole program optimisation and various advanced transformations. That's the whole reason why they came up with gimple.

CLR is more high level than LLVM. As mentioned in the main LLVM paper (http://llvm.org/pubs/2004-01-30-CGO-LLVM.ps ):

***
[Smalltalk, Self, Java, CLR]
Note that these systems all represent a program in a much higher (and language specific) representation than LLVM does. Although this presents a lot of high-level information to the runtime optimizer, it also makes it largely impossible for the static compiler to do a meaningful amount of optimization before runtime. As mentioned in Section 1.1.2, this requires the runtime optimizer to perform many mundane optimizations at runtime just to get acceptable code, which makes aggressive optimizations even more costly.
[...]
Another strength of LLVM is that it does not require a specific object model, set of exception semantics, or any other high-level language feature from a front-end. This makes it very flexible, but a set of inter-language conventions would need tobe defined to allow code produced by different front-ends to communicate (an LLVM Application Binary Interface, or ABI).
***

BTW: it is possible to "up-compile" LLVM bitcode into CLR. There even is a proof-of-concept backend for that, but nobody is interested enough in that functionality to maintain it (so it doesn't work anymore).

Jonas

In our previous episode, Felipe Monteiro de Carvalho said:

True.
Note: that we typically use a PIC print as a realtime device between our vision PC, and the clients systems (PLC's and I/O signals). This because most of the customers PLCs are old and/or have high cycle times, but came with the machinery, so can't be replaced easily.

If you uc only has one function, you could try to do that. But we have multiple functions, and several might need a quite high speed IRQ. (currently up to 50KHz), and still do other stuff. Reliability is also a point.

Using the motorcontrol (and other on PIC hw) saves on high speed IRQ and/or load in the uc's main loop, making those free for other, more custom purposes.

We don't typically use the motor control to control motors, but to get quadrature encoder input. Typically 10-25KHz, but higher values have happened. Sometimes we have additional quadrature encoders on ordinary pins (after exhausting the one or two hw ones)

So the main reason for using HW as much as possible is to keep the actual uc free as much as possible for other tasks. It is not that much that you couldn't stuff it all on a slower one manually, but more the validation required for that if something is added, which often can only be done when hooked up to the customers hardware etc etc.

And we only deliver one uc per machine, and the BOM lists among others several 2000 euro cameras. So 3 or 4 euro more to go from a basic PIC24 to the topmodel dspic doesn't really hurt. The pain is more in making the prints and adding the components to them.

Besides (sometimes several) motorcontrols, the dspics are also faster, up to 40MHz (at least before the most recent roadmap)

look at ARM7, you have second source, good performance and a very nice compiler ;-)

Regards, Bernd.

Having PWM by setting simply some registers and hardware controlled dead times in the bridge circuits makes your programs much more simpler and robust.

Marco van de Voort wrote

So the main reason for using HW as much as possible is to keep the actual uc free as much as possible for other tasks.

yes, this is why I consider to use an ARM7 controller "in front of" an ARM9 (Linux) controller, although the ARM9 should have the power to handle my realtime stuff.

Regards, Bernd.

In our previous episode, Bernd Mueller said:

Can't you simply get an ARM with some of the relevant hardware integrated?

Thanks a lot for the pointers !

-Michael

the ARM9 has most of the relevant hardware integrated. The unknown factor for me is to deal with Linux (which is required for the project). Writing kernel driver (at DMA/interrupt level) is certainly doable, but I fear the problems I could get with this approach since I am relatively new to ARM-Linux. If things go well, I still can later remove the ARM7.

Regards, Bernd.

I'm going to use the PIC24 series, as same features an USB interface.

-Michael

yes, this is why I consider to use an ARM7 controller "in front of" an ARM9 (Linux) controller, although the ARM9 should have the power to handle my realtime stuff.

This is why I decided to handle this kind of complexity with an FPGA with embedded (Linux-) Processor. The fast stuff can be done in HDL while the processor can take it's time to do the complex stuff. And we only have a single chip that (other than special processor chips) is very unlikely to become unavailable any time soon. And if the FPGA chip used is discontinued, there will very likely be a bigger compatible one.

-Michael

Michael Schnell wrote

This is why I decided to handle this kind of complexity with an FPGA with embedded (Linux-) Processor.

which system/vendor did you choose?

Regards, Bernd.

We are going to design some controller boards with Altera Cyclone III FPGAs. The "NIOS" processor is optimized for this FPGA architecture, is very easily implemented into the HDL design, offers acceptable features and speed (100 MHz, some 50 bogomips), can be selected to come with or without MMU and there is a very active Linux community.

I have a "NEEK" demo board (with 32 MB DRAM) from Altera and Linux runs very nicely on it (including Ethernet, touch-screen based nano-X etc.

-Michael

In our previous episode, Michael Schnell said:

I'm going to use the PIC24 series, as same features an USB interface.

I had bad experiences using the PIC18 with USB interfaces (bad latency, loss of connection without automatic reconnect). We reverted to RS232/RS422, and are experimenting with the newer ethernet versions.

Michael Schnell wrote

> which system/vendor did you choose? We are going to design some controller boards with Altera Cyclone III FPGAs. The "NIOS" processor is optimized for this FPGA architecture, is very easily implemented into the HDL design, offers acceptable features

How big is the implementation? In LUTs, FFs, BlockRAMs?

Micha

How big is the implementation? In LUTs, FFs, BlockRAMs?

For Linux you need the biggest processor ("f") which (in Altera speak ) needs 1400..1800 LEs and three M4Ks. I don't kn ow how LEs translate to LUTs and FFs. M4Ks are 4 K Bit block RAM units. You can configure I and D Caches which of course costs additional resources.

AFAIR, $8 Cyclone has room for some four of those processors.

-Michael

I had bad experiences using the PIC18 with USB interfaces (bad latency, loss of connection without automatic reconnect). We reverted to RS232/RS422, and are experimenting with the newer ethernet versions.

Thanks for the warning. I am going to discuss this with the FAE.

Did you use host or device mode ? [Sounds like device, we are going to use the host mode of the OTG enabled chip.]

-Michael