Re[3]: [fpc-other]reputation of Pascal

[Florian Klaempfl]

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.


> > I'am too lazy to look up the web for the instruction set of TC1775 :)
> > but what kind of instruction set does it use?
>
>It is quite different to the i386 instruction set. First, it is RISC
>with Load/Store architecture.

This isn't a real problem :)

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


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

>A "Linked jump"
>is like the Call on 8086, without context saving. And normal "Jumps" are
>there too. Conditional ones too.
>
>I don't know how the compiler can handle all that specialities, but, on
>the i386 there are other specialities, so, I guess, that won't be _that_
>a big problem.

No.


> > Yes, a lot is already done though it isn't finished yet.
>
>Ah, great. Does that mean an Itanium port is easily possible as well?
>:-)

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.


> > >Here are three specialities:
> > >  1) "interrupt 12" ... this should tell the compiler to automatically
> > >     put this procedure to the interrupt vector table (or whatever the
> > >     µC uses)
> >
> > No problem.
>
>I want to mention, that there are two different interrupt service
>providers in the chip. :-) The normal CPU, for which standard opcodes
>can be used. In the Interrupt Vector Table (which is like that one in
>the 8051, so not an address is there, but code. Some instructions can be
>kept there. If one needs more, a jump to somewhere else can be made.
>
>Another thing is the special Peripheral Control Processor. It has
>opcodes too, with lots of common instructions, but very different from
>the main CPU core. It is there to do easy interrupt handling, like
>querying the AD converter and writing the value to a RAM region.
>Therefore it would be extremely nice, to have this as a normal interrupt
>procedure within a .pas file. Sure, only a subset of constructs can be
>used, but it would be nice! Veery nice! ;-)

Should be possible, i.e. for the compiler it mainly means the instruction set
is limited in certain areas of the code.


> > >  2) "static" ... this variable should be static. I think using "Const"
> > >     instead of "Var" would do the job.
> > >  3) "P12.1" ... direct access to bits of bit addressable
> > >     registers/memory
> >
> > This is a little bit more difficult, but it is possible.
>
>Thinking of the Keil C compiler they have all this mentioned extentions
>for the 8051 and the C166 µC. I think, inventing a new syntax for such
>things is not necessary, "P12.4" is enough.
>
>BTW: There are nice instructions to copy bit fields. You have a 32 bit
>value, and say, you want bits 7..23, so it takes them and moves to
>another register, beginning at bit 0. Such "bit stream take" operations
>would be nice too for Pascal. It can combine two registers to a 64 bit
>value and take bits across the border! Very nice for shift and rotate
>operations!
>
>SIMD instructions are there too. And it can work with "real" valued
>variables in 1.31 and 1.15 format. The range is -1.0..+1.0-1LSB. Perhaps
>such a data type for Pascal would be nice too. A FFT is easily
>implemented because of the cyclic buffer and the bitreversed addressing
>modes. And block adjust for a lot real values at once (for fixed point
>FFT) is availaible too.
>
>Min, Max instructions are there too. *cantstopbeingenthusiastic* :-)

And you do it call RISC ;) ?


> > It simply depends on the linker you use. FPC itself (can) output(s)
> > assembler so it's up
> > to you to use the right assembler and linker.
>
>Ah, I see. Fine, I'll investigate from this point.

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


>Does that mean that a port to another processor has to have the
>interface to the selected assembler, so that the opcodes, special
>commands, ... fit together?

Yes.


>So, the i386 output module uses AT&T
>assembler style, the TriCore output module use a totally different
>style?

Yes.

> > You can use a dummy system unit, for the basic types like integer etc. 
> a tiny
> > system unit is necessary. I guess it's already available in rtl/fakertl.
> > For an example for a small system unit have a look at PalmOS System unit
> > (rtl/palmos).
>
>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.