[fpc-devel]TriCore Port

[Johann Glaser]

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 and now is in the fpc-devel list.

> >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* ;-)

> >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? Would it being possible to use
several protection levels (0, 1, Superuser) within Pascal by some kind
of implementation?

> 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. 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. 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. :-)

> >Min, Max instructions are there too. *cantstopbeingenthusiastic* :-)
> 
> And you do it call RISC ;) ?

I also had this thought when writing the text above. :-)

I'm not an informatician but an electrician. My understandig of "RISC"
is, that the instructions only have access to the registers and there
are additional load/store instructions. CISC has complex addressing
modes like the i386. But, it's only a weak conclusion out of a single
sentence in the User Manual. :-)

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

> >Great! Can such a system unit consist of 0 bytes of code? Only type
> >declarations in, no code?
> 
> Theoretically yes, but some bytes of startup code would be nice so
> that the automatic initialzation of units can be done etc.

For a microcontroller exaclty this is unnecessary, because there is only
_one_ program in, the operating system. Perhaps this OS can implement
loading of applications, so that there should be another mode for FPC to
make loadable apps. But for the OS there is no startup code, because
this is a procedure somewhere in the "application"'s Pascal sources.
This procedure is "magically" executed as soon as the CPU is released
out of reset. As if it was a callback, or so. Better: equal to an
interrupt procedure, but without a _return_ condition. The "Reset" ISR
would end in an endless loop, or an "Idle;" instruction, which holds the
processor in power saving waiting for an interrupt. But the interrupt
then jumps itself to the appropriate procedure, executing what has to be
done.

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".
Is the FPC core able to handle this? :-)

Bye
  Hansi

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