Bernd Mueller schrieb:
>> 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
Marc Santhoff wrote:
Am Dienstag, den 09.12.2008, 09:53 +0100 schrieb Marco van de Voort:
In our previous episode, Marc Santhoff said:
some small THUMB things, but FPC doesn't generate THUMB code).
One possible difference coming to my mind (although only a speed issue,
not influencing nonethel
Am Dienstag, den 09.12.2008, 09:53 +0100 schrieb Marco van de Voort:
> In our previous episode, Marc Santhoff said:
> > > some small THUMB things, but FPC doesn't generate THUMB code).
> >
> > One possible difference coming to my mind (although only a speed issue,
> > not influencing nonetheless w
Bernd Mueller wrote:
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. Th
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 che
In our previous episode, Marc Santhoff said:
> > some small THUMB things, but FPC doesn't generate THUMB code).
>
> 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
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 gener
Am Montag, den 08.12.2008, 15:04 -0600 schrieb Prince Riley:
> 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 asse
On 08 Dec 2008, at 22:00, Prince Riley wrote:
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
I did not understand your questio
Marc,
Just wanted to say thank you for that info.. much obliged.
Prince
On Mon, Dec 8, 2008 at 2:14 PM, Marc Santhoff <[EMAIL PROTECTED]>wrote:
> Am Montag, den 08.12.2008, 13:43 -0600 schrieb Prince Riley:
> > Perhaps the person who coded that support into FP can write back and
> > say which A
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
Am Montag, den 08.12.2008, 13:43 -0600 schrieb Prince Riley:
> 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 Ach
On 08 Dec 2008, at 20:43, 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
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
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
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 ca
Am Montag, den 08.12.2008, 10:27 +0100 schrieb Jonas Maebe:
> On 08 Dec 2008, at 00:33, Prince Riley wrote:
> > 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 additio
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 extre
On 08 Dec 2008, at 00:33, Prince Riley wrote:
On Sun, Dec 7, 2008 at 4:53 PM, Jonas Maebe
<[EMAIL PROTECTED]>wrote:
On 07 Dec 2008, at 23:01, Prince Riley wrote:
"FPC does not specify any particular sub-architecture to the
assembler."
was not an opinion or a guess, but a fact. What sub-a
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
On 07 Dec 2008, at 23:01, Prince Riley wrote:
On Sun, Dec 7, 2008 at 3:11 PM, Jonas Maebe
<[EMAIL PROTECTED]>wrote:
On 07 Dec 2008, at 00:30, Prince Riley wrote:
A few additional points if I may ..
When you say the FP supports the ARM architecture my specific
question is
how does FP '
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
On Sun, Dec 7, 2008 at 3:11 PM, Jonas Mae
On 07 Dec 2008, at 00:30, Prince Riley wrote:
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 ...
FPC does not specify any particular sub-a
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
On 06 Dec 2008, at 23:32, Prince Riley wrote:
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 guess y
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
semanti
26 matches
Mail list logo
