Hello

I have read on the wiki that FP supports ARM.. which I find very interesting..

After reading the manuals I see that FP uses the GNU tools as back-ends and they support ARM ... but it that the extent of the support here. For example, the ASM directive in FP targets the IA33 processor semantics/syntax ...not ARM ..

I am not opposed to working up the missing pieces if that's necessary, but before beginning that work, I wanted to check with the group and see if anyone had already started down this road and if so how far along have you gotten ?

Thanks

Pricne

I guess you mean IA32 rather than IA33. Anyway, FPC is always compiled with support for creating code for one single cpu architecture. The currently supported ones are i386 (=IA32), x86_64, powerpc (32 bit), powerpc64, sparc and ARM. Apart from generating code for one such architecture, every such compiler can also only parse assembler code written for that same architecture (since there is no way the compiler can translate assembler code written for one architecture into assembler code for another architecture).

ARM support works fairly well (except for EABI support, which still has some bugs).

Jonas

Hello

Thanks for that reply ... and yes I meant IA32

A few additional points if I may ..

When you say the FP supports the ARM architecture my specific question is how does FP 'inform' the GNU assembler back end of which ARM architecture is intended ...

The following is just a snippet from the GNU Assembler manual showing the ARM processore option codes ...

-mcpu=processor[+extension...]
This option species the target processor. The assembler will issue an error message if an
attempt is made to assemble an instruction which will not execute on the target processor. The
following processor names are recognized: arm1, arm2, arm250, arm3, arm6, arm60, arm600,
arm610, arm620, arm7, arm7m, arm7d, arm7dm, arm7di, arm7dmi, arm70, arm700, arm700i, arm710, arm710t, arm720, arm720t, arm740t, arm710c, arm7100, arm7500,
arm7500fe, arm7t, arm7tdmi, arm8, arm810, strongarm, strongarm1, strongarm110,
strongarm1100, strongarm1110, arm9, arm920, arm920t, arm922t, arm940t, arm9tdmi, arm9e, arm946e-r0, arm946e, arm966e-r0, arm966e, arm10t, arm10e, arm1020, arm1020t, arm1020e, ep9312 (ARM920 with Cirrus Maverick coprocessor),
i80200 (Intel XScale processor) iwmmxt (Intel(r) XScale processor with Wireless MMX(tm)
technology coprocessor) and xscale. The special name all may be used to allow the
assembler to accept instructions valid for any ARM processor. In addition to the basic instruction set, the assembler can be told to accept various extension
mnemonics that extend the processor using the co-processor instruction space. For example,
-mcpu=arm920+maverick is equivalent to specifying -mcpu=ep9312. The following extensions
are currently supported: +maverick +iwmmxt and +xscale.

I need to be clear on how FP specifies one of these option and how the 'assemble' directive within the FP syntax is implemented to use ARM register and assembler sematics/syntax which the GNU Assembler assumes will be set by the language 'front end'

Thanks

Prince

FPC does not specify any particular sub-architecture to the assembler. I guess this means it's just a generic ARMv4 (i.e., ARM7 and above).

Jonas

Jonas

Thank you for that reply.

OK.. well if that opinion is just a guess, then as this is really a question that has to be answered by actually looking at the FP code and finding out what it sets as the ARM specific GNU AS command line options.

Prince

"FPC does not specify any particular sub-architecture to the assembler." was not an opinion or a guess, but a fact. What sub- architecture the GNU assembler picks in that case (i.e., by default) was the guess.

Jonas

My point is saying 'guess' was not to discredit your statement about what the FP compiler does, rather to say that no one seems to know exactly what ARM option FP sends to the GNU Assembler and what that option value actually is.

Reading the GNU as manual, the arch parameter value needs to be set to one of several values. It can also specify generic ARM architecture, but that choice in addition to being imprecise, could result in code that either is not optimized for the target ARM processor, or fail to execute as expected.

Thank you for your reply.

Prince

I don't understand how the following are not in contradiction: a) "FPC does not specify any particular sub-architecture to the assembler." (me)
b) "no one seems to know exactly what ARM option FP sends to the GNU Assembler" (you)

The answer is still "FPC passes no ARM sub-architecture option to the assembler."

It will at most cause the assembler to reject opcodes for particular ARM sub-architectures that do not exist in the default sub- architecture (which without a doubt is a generic and common ARM variant). Crashes only occur if you tell the assembler to accept e.g. ARMv6 opcodes, and you genere such opcodes, and then you try to run the program on an ARMv4 cpu. I'm not aware of any optimisations that the assembler can perform for different ARM architectures (except for some small THUMB things, but FPC doesn't generate THUMB code).

Jonas

Jonas Maebe wrote

... the assembler can perform for different ARM architectures (except for some small THUMB things, but FPC doesn't generate THUMB code).

I'd wondered about THUMB support. That means no STM-32 processors, as THUMB code is all they execute. Bummer, as they are nice and extremely cheap.

Jeff.

One possible difference coming to my mind (although only a speed issue, not influencing nonetheless working code):

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.

It would be nice to have the chance of setting some extra command line arguments to the call to the assembler - I think that is what Riley is is asking for.

From a quick look over the man pages of as and gcc there seems to be no

environment variable or such for switching the assembler output code from the outside.

Marc

That's a compiler and not an assembler decision.

Jonas

Yes, you're right, sorry. Code generator issue, that is.

Marc

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

Prince Riley wrote

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?

As already mentioned by Jonas: it is the Achitecture v4.

Look there for reference:

http://www.arm.com/products/CPUs/architecture.html

Marc

Prince Riley wrote

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?

The problem was that you never asked for which ARM architecture FPC generates assembler code, but only which ARM sub-architecture parameter FPC passes to the GNU assembler. Those are two completely separate questions (and unrelated in this case).

By default, FPC generates ARMv4 architecture code. You can also ask for ARMv5 and ARMv6 code (using the -Cp command line option, see "ppcrossarm -i" for the possible options).

In practice, the only difference at this time is that the prefetch() statement is not translated into assembler code unless you target ARMv6 (because earlier ARM cpus do not have a prefect assembler instruction).

To be clear ARM5 and ARM7 aren't variants, they are RISC family processors to be sure, but they are 'different.'

They are variants of the same processor family (just like the i386 and the Core2Duo are variants of the same processor family). The fact that they are variants does not mean that they support exactly the same instruction set.

Jonas

Sorry, I think you are mistaken.. I did ask which ARM Architecture and if you follow the thread back you'll see I even gave examples of what the assembler options were for ARM

Here is the text of that post ....

===========================================
Thanks for that reply ... and yes I meant IA32

A few additional points if I may ..

When you say the FP supports the ARM architecture my specific question is how does FP 'inform' *the GNU assembler back end of which ARM architecture is intended ..*.

The following is just a snippet from the GNU Assembler manual showing the ARM processor option codes ...

-mcpu=processor[+extension...]
This option speci es the target processor. The assembler will issue an error message if an
attempt is made to assemble an instruction which will not execute on the target processor. The
following processor names are recognized: arm1, arm2, arm250, arm3, arm6, arm60, arm600,
arm610, arm620, arm7, arm7m, arm7d, arm7dm, arm7di, arm7dmi, arm70, arm700, arm700i, arm710, arm710t, arm720, arm720t, arm740t, arm710c, arm7100, arm7500,
arm7500fe, arm7t, arm7tdmi, arm8, arm810, strongarm, strongarm1, strongarm110,
strongarm1100, strongarm1110, arm9, arm920, arm920t, arm922t, arm940t, arm9tdmi, arm9e, arm946e-r0, arm946e, arm966e-r0, arm966e, arm10t, arm10e, arm1020, arm1020t, arm1020e, ep9312 (ARM920 with Cirrus Maverick coprocessor),
i80200 (Intel XScale processor) iwmmxt (Intel(r) XScale processor with Wireless MMX(tm)
technology coprocessor) and xscale. The special name all may be used to allow the
assembler to accept instructions valid for any ARM processor. In addition to the basic instruction set, the assembler can be told to accept various extension
mnemonics that extend the processor using the co-processor instruction space. For example,
-mcpu=arm920+maverick is equivalent to specifying -mcpu=ep9312. The following extensions
are currently supported: +maverick +iwmmxt and +xscale.

*I need to be clear on how FP specifies one of these option and how the 'assemble' directive within the FP syntax is implemented to use ARM register and assembler sematics/syntax which the GNU Assembler assumes will be set by the language 'front end'*

==================================================================

if you look at this list you'll see that ARM3,6, and 7 are among the options.

So back then, as I have up to now, I asked which assembler code option ( meaning -- which ARM architecture --) did FP support.

Marc,

Just wanted to say thank you for that info.. much obliged.

Prince

I did not understand your questions that way

Answer: it does not inform the GNU assembler back end of which ARM architecture is intended. The code generator is not "the GNU assembler backend".

[snip GNU as command line options to select ARM variants]

*I need to be clear on how FP specifies one of these option

Answer: it does not specify any of those options.

Answer: the frontend (the compiler) does not set any architecture option for the GNU assembler.

================================================================== if you look at this list you'll see that ARM3,6, and 7 are among the options.

Yes, but that's not the point. I think the confusion stems from your usage of "(GNU) assembler", by which you meant "code generator". The code generator is not part of the (GNU) assembler, but part of the compiler.

The "assemble" part of the compiler only consists of either calling an external assembler (such as the GNU assembler) or using the internal assembler (e.g., for IA32 and x86_64) to convert the code generated by the code generator into object code. Code selection happens before that phase.

The way it basically works is scanner -> parser -> code generator -> assembler -> linker. The scanner converts the source code into tokens, the parser converts those tokens into a parse tree, the code generator converts the parse tree into assembler code, the assembler converts the assembler code into object code, and the linker links together all object code (and libraries) into a program or library.

Jonas

Prince Riley wrote

Marc, Just wanted to say thank you for that info.. much obliged.

If you want to know more about what code the compiler produces there are two more opportunities:

First you can tell the compiler to not delete the intermediate assembler files and look inside how statements are translated (e.g. for integer multiplication) by using

fpc -a ...

Call fpc without arguments for more info.

Secondly you can look inside the sources of the compilers code generator itself (no, dunno which file).

HTH,
Marc

So, the situation is like this:

1) Target ARM architecture needs to be "told" to FPC since FPC needs this information to do correct code generation.

2) FPC does not inform GNU assembler of intended ARM architecture for which assembler code is generated for, which doesn't prevent GNU as from generating correct binary.

3) GNU as doesn't check if FPC-generated instructions are valid, because it does not know target architecture for which it is assembling. But (as stated in previous point), GNU as is still able to generate correct binary.

Correct?

Greets,
Aleksa

In our previous episode, Marc Santhoff said:

Wikipedia also calls ARM7 ARMV3 arch, and only ARM7TDMI ARMV4. This could be the reason why. (and maybe the D and the I)

It would be nice to have the chance of setting some extra command line arguments to the call to the assembler - I think that is what Riley is is asking for.

The trick is that if you give FPC that info, it can check both code generated and the assembler reader, and do the same AND provide a valid source line. IOW, I don't see a good reason to do this in the backend assembler, if it can be better done in the frontend.

For the rare (e.g. FPC development related) cases, simply make a few scripts with systematic naming that call the assembler with the right params, and then select the desired one using -XP.

IIRC the buildfaq has an example of this (for the -m params)

Aleksa Todorovic wrote

So, the situation is like this: 1) Target ARM architecture needs to be "told" to FPC since FPC needs this information to do correct code generation.

At least up to fpc 2.2.2, the compiler does not use any information about the ARM architecture. There is one runtime check in the RTL which tries to detect if the architecture is newer than ARMv4. If this is the case, the RTL uses an optimized move function.

Regards, Bernd.

the RTL for ARM-Linux, I forgot to mention.

Regards, Bernd.

Since I've been enlighted that I'm mistakenly ignored the fact that fpc does the code generation and since ARM v4 is only mentioned on ARMs web site as an ancient architecture mostly faded away I'm strongly with you:

The compiler(s code generator) should take care of target cpu variants and architectures.

Or compile the assembler for the desired target cpu as default value if possible.

But since the only ARM powered board I'm dealing with runs on FreeBSD there is no fpc compiler yet. And no urgent need to have one.

Marc

http://www.arm.com/products/CPUs/architecture.html

Citation:
"ARMv4
The oldest version of the processor architecture supported today. All previous versions are now obsolete. Implementations include some members of the ARM7™ processor family and Intel StrongARM® processors. ARMv4 can be considered a 32-bit ISA operating in a 32-bit address space."

Maybe, the fancy pictures on the ARM website concerning the ARM architectures could lead to the assumption, that ARMv4 is mostly faded away ;-) But this is not correct. A lot of ARM7 embedded controllers are ARMv4 devices, including ATMEL AT91SAM7x, NXP LPC2x and STM STR7x. FPC targets them perfectly. BTW the Openmoko Neo 1973 and Neo FreeRunner use a Samsung S3C2442 (ARM9) which is ARMv4 too.

The compiler(s code generator) should take care of target cpu variants and architectures.

I think, this would be a lot of work. Which architecture should be implemented first? ARMv5 or better the latest ARMv7 (CORTEX) variants. But what about the Thumb/Thumb-2 instruction set? Also very interesting.

From my point of view the current situation with FPC/ARM is pretty good. And if someone really needs architecture specific implementations, he could try to add these features to the compiler.

Regards, Bernd.

There are very little *generally* usefull instrustrutions in ARMv5 and ARMv6, most are only usefull for very limited applications. FPC makes use of the most important one: PLD in the move procedure and it is detected dynamically if it's available.