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.
Show quoted text 8 lines
>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* ;-)
Show quoted text 6 lines
>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?
Show quoted text 5 lines
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?
Show quoted text 5 lines
>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
