[fpc-pascal] Free Pascal Support for ARM Architecture

[Prince Riley]

Sorry to everyone for replying so far down the thread to the points
mentioned earlier.

The FPC ARM support is stated as ' does not specify an ARM architecture' ...
fine ..but there is a major issue there that needs clarification and better
documentation.

Is it really safe to have no way to target the entire compiler (FP code and
assemble op codes that are passed thru) output to a specific ARM processor?
Since the back end GNU as supports several variants of ARM, why is FP
limited to an unspecified ARM processor?

If FP compiler is outputting ARM assembler code for the entire program, and
the assembler ignores invalid ARM opcodes, without specifying what ARM
sub-architecture (ARM7, ARM5, ARM9), then what defines which ARM op codes
are 'invalid' ?

I realize that at the time someone may have thought it really didn't made
any difference, but as was mentioned in this post, several ARM processors do
not have multipliers. So what happens when  one writes a FP function that
multiplies two numbers? How does the complier choose to output ARM ADD
opcodes instead of MULTIPLY opcodes? Does the FP compiler just use ADD
opcodes all the time?

What I keep asking here and not getting a precise answer about is what
specific ARM opcodes does the FP support What is its default ARM
architecture is the opcode spec based on? To be clear ARM5 and ARM7 aren't
variants, they are RISC family processors to be sure, but they are
'different.'

Perhaps the person who coded that support into FP can write back and say
which ARM op codes look-up table it uses generating the FP compiled code. Is
it ARM7? Is it ARM9?, Is it ARM4/5?

Thanks

Prince


On Mon, Dec 8, 2008 at 12:27 PM, Marc Santhoff <M.Santhoff at t-online.de>wrote:

> Am Montag, den 08.12.2008, 19:22 +0100 schrieb Jonas Maebe:
> > On 08 Dec 2008, at 18:26, Marc Santhoff wrote:
> >
> > > There are some ARM7 (and maybe ARM9, not sure) core variants having no
> > > hardware multiplication unit. IIRC the M in TDMI stands for "hardware
> > > multiplier unit". Experiences with gcc showed me that the 32x32=64
> > > mult
> > > commands are not used in that case.
> >
> > That's a compiler and not an assembler decision.
>
> Yes, you're right, sorry. Code generator issue, that is.
>
> Marc
>
>
> _______________________________________________
> fpc-pascal maillist  -  fpc-pascal at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20081208/8358aa93/attachment.html>