[fpc-devel]TriCore Port

[Florian Klaempfl]

At 18:54 10.06.02 +0200, you wrote:
>Hi!
>
> > Since this message does fit into fpc-devel, I sent it to fpc-devel as well
> > and I think we should continue the discussion there.
>
>Ok, it has a new subject

Ooops, I forgot about this :)


> > >But it has far more instuctions than the
> > >i386. :-) They have some additional opcodes for bit operations,
> > >arithmetic (very much different behaviour on different data types,
> > >including saturation), ... But, the instructions are very interesting
> > >and useful.
> >
> > Could be support by some kind of intristic functions which are inlined by
> > the compiler.
>
>My worry is that Pascal doesn't even have constructs which are
>equivalent to the nice capabilities of the TriCore. But, hmm, the i386
>also has some nice capabilites, only utilized by the optimizer, not the
>Pascal programmer himself.
>
>The TriCore has some DSP extentions, which are _very_ usefull when doing
>DSP stuff. It would be really nice being able to use such things in
>Pascal syntax to implement effective algorithms. So, FPC would be the
>first compiler with DSP capabilites. *dreaming* ;-)

FPC has this already :)

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

    ...
    a1:=a2+a3;
    ...

?


> > >A problem might be the register handling. There are A0..A15 as address
> > >registers and D0..D15 for data. Each 32 bit wide. When doing a "CALL"
> > >_some_ of them are saved into the "Context Save Area".
> >
> > This do some other processors as well. It's only a matter of the calling
> > conventions which differs anyway from processor to processor.
>
>Ah, I see. Yesterday I read in the TriCore manual that by convention
>compiliers use A0 and A1 (address registers) for it's constant
>addresses, where A8 and A9 are used to supply other addresses. The
>TriCore only saves A2..A7 and A10..A15 in the CSA, A0,A1,A8,A9 are kept,
>so they are global address registers. One can even lock these registers
>so that they are protected and cause an exception (=trap) when altered.
>
>BTW: doing system programming for microcontrollers needs heavy usage of
>internal register, e.g. for protection adjustments, hardware, ... Is it
>possible to implement that very internal things to the system unit with
>special treatment by the compiler?

Of course, this can be done

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


> > I'am already working on an iA64 (Itanium is one particular implementation
> > of the iA64 architecture)
> > port though it is delayed because I want to do the x86-64 port first
> > because it seems to be the
> > more important archiecture in the short term.
>
>Aha. (BTW: TC1775 is an implementation of the TriCore core too). Hmm,
>Itanium might never be owned somebody privately, because of their price.
>Despite it is a fascinating processor. :-)
>
> > Should be possible, i.e. for the compiler it mainly means the 
> instruction set
> > is limited in certain areas of the code.
>
>Hehe, there comes another important thing in. The CPU has different
>memories as the PCP. Both have their associated Data and Programm
>memory. Harvard architecture. But I think they are mapped in the 4GB
>address space somewhere.
>
>And the instruction set is totally different, what I've found out until
>now.
>
>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".

>I need an
>output which can be fed directly into the memory.
>I plan to write the OS
>(big word for a little thing) in FPC, if it is possible. So assigning
>memory regions is necessary.
>
>Telling it the linker in some kind of a Makefile is the way I don't
>like.

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.

>  I dream of the following:
>
>{ in an application, for example signal processing }
>Const FIR_coeff : Array[0..31] of LongInt; CPU_Data_Memory;
>       PCM_A     : Array[0..7]  of Integer; PCP_Data_Memory;
>
>{ ports, core registers, ... in the system.pas unit }
>       P1        : BitField[16]; absolute $FFFC8AC2; SFR;
>       PSW       : LongInt; absolute $FFFFFE04; CSFR;
>       CDC       : BitField[7]; absolute PSW.[6..0];
>
>:-)) Would be nice, that way. :-)

This is no problem, it's only a matter of implementing it.

>I'm not an informatician but an electrician.

Me too :)


> > The first step to support a new processor is to
> > implement the similar files to i386\cpubase.pas, i386\cpuinfo.pas
> > and i386\cpuasm.pas. After this the assembler write can be implemented
> > and the code generator which is the most work probably ...
>
>Hmm, is that related to the 1.1 or the 1.0 branch?

1.1

>BTW: Each interrupt procedure has, lets say 64 bytes of code reserved at
>the interrupt entrance point (as explaned, no vectors like in 8086 or
>IDT in PM of i386, but entrance points, where code must be). One can put
>a short ISR there, including the "IRET" (don't know the TriCore
>mnemonic). If the ISR is longer, one uses a "Jump" as last instruction
>jumping somewhere else, doing the rest, and then executing the "IRET".

This looks like a task for the assembler/linker to me.

>Is the FPC core able to handle this? :-)

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.