[fpc-devel]TriCore Port

[Johann Glaser]

Hi!

> Ever tried
> {$MMX+}
> var
>     a1,a2,a3 : array[0..7] of byte;
> 
>     ...
>     a1:=a2+a3;

Aaaaahh. Great. Does this work with "*" too? And compare, ...

> >Would it being possible to use
> >several protection levels (0, 1, Superuser) within Pascal by some kind
> >of implementation?
> 
> Hmm? What do you mean with this? Memory protection on software level?

Nono, the processor itself has protection mechanisms. Similar to that of
the 80386, but less grained. It has no GDT, LDT, IDT (though the amazing
features possible are not used in modern OS' on i386 platforms, but only
flat memory model :-( ), but it has protection levels (0, 1 and
SuperUser) which inhibit the task to access hardware,
SpecialFunctionRegisters, ...

> >It would be necessary that FPC (i.e. the linker) generates seperate .hex
> >files for each of them. Intel Hex output is very important to load it
> >into the on chip memory. µC are a totally different world. You don't
> >generate an executable as a file, and the OS will execute it.
> 
> Is there any important difference? You may know the old
> DOS .COM executable format, it's similiar to a.out: basically
> a flat image of the memory. If it doesn't contain
> any external references you can simply store it in a ROM
> as "OS".

Really? I didn't know that. I thought an "a.out" file is an ELF binary.
(from GCC) But, you are right, there are two different executable
formats, a.out and ELF (supported by the kernel). Ok, I'll have a look
at the a.out file format.

> Hmmm, but I guess you'll working with more than one unit and at this
> point you need some kind of linker. It doesn't matter if outputs
> an executable or a .hex file.

Yes sure. A little difference is, because "excutables" are loaded by the
OS, they don't have fixed memory regions, and they most likely don't
have access to direct processor (CPU) features like SFRs, interrupt
tables, ... 

A Firmware for a µC does definitely need such things. But it doesn't
need relocatability, dynamic linking, memory management, ... And most
likely no OOP (despite it would be nice to write an OS with OOP even in
its depth :-) ).

> Of course it is ;). To be serious: FPC is designed very "open", it's possible
> to implement almost everything, it's only a matter of implementing it.
> I can give advise and do also some work for a TriCore port but the main
> part of it must be done by somebody (you :) ?) else.

First of all thank you for the many good ideas and hints. I developed
many ideas myself within this thread. Currently I have several projects
I want to do, but no time. And I hope it doesn't end up that I've spoken
a lot (hot air) without doing serious work. I'm definitly interested in
a FPC port for TriCore (even if I stay the only user of it :-) ), but it
will take some time.

In my opinion it will be the best when I first make a list of what would
be nice to have
 1) at the front end (i.e. in Pascal syntax, e.g. "interrupt 12;", ...)
 2) at the back end (usage and utilisation of TriCore instructions)
After that we can discuss how to implement and I can start the work.

Thanks
  Hansi

-- 
Johann Glaser   <Johann.Glaser at gmx.at>
   Vienna University of Technology
       Electrical Engineering 
____ http://www.johann-glaser.at/ ____