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

Johann Glaser Johann.Glaser@gmx.at
10 Jun 2002 14:40:42 +0200


Hi!

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

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

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

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

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

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

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? So, the i386 output module uses AT&T
assembler style, the TriCore output module use a totally different
style?

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

Bye
  Hansi

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