Hi
I receive error while compile for arm
selected processor does not support 'ldfd f0,[r11,#-48]'

this is from simple function, but when I move them to main unit everything is compiled OK

what does it mean?

Dariusz Mazur wrote

I receive error while compile for arm selected processor does not support 'ldfd f0,[r11,#-48]'

Add -Cfsoft to your compiler options to use softfloat instead of FPA.

this is from simple function, but when I move them to main unit everything is compiled OK what does it mean?

I don't know why it doesn't happen in that case.

Jonas

Jonas Maebe pisze:

I've had this option enable

If units I have compiler directive $E- (emulation of FPU)

but when I remove it, i have problem with COMP type
when
var
   c : comp;
begin
   c:=int(1.1);
end;

it claim
got Double, expected int64

second problem is with str

str(c:0:0,ss)
is not valid

Please show a sample program that demonstrates this problem and the full command line that you used to compile it (and copy/paste the options that you used to compile the compiler/rtl).

Is this still about moving the function to another unit solving the problem you had, or an unrelated remark?

Comp is an x87-specific legacy type. On platforms without x87 support it is emulated using int64 (so there it is an integer type rather than a floating point type). You should not use the comp type if you want portable code.

I don't understand what this has to do with what I said above, or with your ldfd-problem though. Please do not reply to some sentences in a previous mail if you want to explain something else, it makes the discussion confusing. Either write a separate mail, or delete the unrelated sentences.

Jonas

This the same, units has enable $E-,
but when I remove it second problem is show.

Now I know where is problem. But how solve them.

I cant simple remove all comp. I try to move my whole program. it use comp hundreds times.
I can't write from ground.

Is this possible to add special directive, that left the same behavior of comp under arm?
or any other hack?

I don't understand what this has to do with what I said above, or with your ldfd-problem though. Please do not reply to some sentences in a previous mail if you want to explain something else, it makes the discussion confusing. Either write a separate mail, or delete the unrelated sentences.

Sorry for confusing.
For me it is the same problem: FPU
but when enable one switch, one bug disappear, but second is show.

Thx for explanation and patience.

Dariusz Mazur wrote

Is this possible to add special directive, that left the same behavior of comp under arm? or any other hack?

Only a hardware hack: solder an x87-fpu on your ARM processor and use that... This cannot be fixed in software without emulating an x87-fpu (or 128 bit floats), because a double precision floating point type does not have the required precision to represent all comp values.

Jonas

Jonas Maebe pisze:

I was thinking, that soft FPU can emulate this, or compiler can use comp internal as int64 and external as real.
But now I remove comp and go one.

From these stage I have one suggestion.
on linux-i368 directive $E claim: switch $E is not supported on linux-arm the same switch cause compiling error (problems with units generating with different switch ) remark: all compiled with -CfSOFT

Darek

It could once someone adds float80 support to it. Currently only single and double are supported.

or compiler can use comp internal as int64 and external as real.

That would result in precision loss.

From these stage I have one suggestion. on linux-i368 directive $E claim: switch $E is not supported

I think that's quite self-explanatory.

on linux-arm the same switch cause compiling error (problems with units generating with different switch ) remark: all compiled with -CfSOFT

Compiling with -Cfsoft and {$E-} will indeed probably causes errors. The compiler should simply give an error when you try to do that.

Jonas

Jonas Maebe pisze:

Why. comp is 8 byte wide, the same as int64,
As I read Delphi help now, comp is internal Intel int64, but is classified as real, because it is not ordinal type.

Not simpler ignore this?
On other platforms this is not enough, and more switches should be added

The precision loss occurs when treating it "external as real", because a double cannot represent all int64 values (it's also 8 bytes, but some of those 8 bytes are used to represent an exponent).

As I read Delphi help now, comp is internal Intel int64, but is classified as real, because it is not ordinal type.

The reason is because x87 fpu supports a signed 64 bit integer type (which Borland called "comp"). They introduced that type to allow people to perform fairly quick 64 bit arithmetic mathematics on the old Intel 16 bit processors, by making use of the floating point unit. That's the reason for the strange the definition and the non- portability.

It may seem simpler at first sight, but putting "intelligence" like that in the compiler only makes the compiler's behaviour more complex to understand in the long run (if the compiler ignores what I'm doing here, under what other circumstances will it ignore things?) and more difficult to maintain.

On other platforms this is not enough, and more switches should be added

I don't understand what you mean with this. Note that we do not support floating point emulation on all platforms.

Jonas

Jonas Maebe pisze:

I thinking about treat this, as it is floating point, not as double it stay integer but it can be use as float (for example str(c:0:0,aa) where s is comp
the same as Delphi

If FPC not support emulation, then $E cant disable this maybe easer is don't disable at all
(but this is only suggestion, no pressure)

It would not be the same as in Delphi (or as in FPC for platforms that support the x87 fpu), because str(c:0:0,aa) would either a) convert the comp into a double, because the implementation of str(x:0:0,...) only exists for floating point numbers b) require a separate comp/int64 implementation of all existing routines that take floating point numbers as arguments, which emulates for int64 whatever the floating point variant of that function does

Jonas