Did ASM syntax changed for PB 6.00 alfa?

[Olli]

Code: Select all

; fsincos in C Backend
Define rcos.f, rsin.f, angle.f=3.141
! asm volatile("fsincos" : "=%&t" (v_rcos), "=%&u" (v_rsin) : "0" (v_angle));
SetClipboardText(StrF(rsin)+" "+StrF(rcos))
; 0.0005926211 -0.9999998212

And thank you juergenkulow for this adaptative way.

[Psychophanta]

I think none of you got the point.
Now you will get it with this short good explanation.

Les say I have this program, in pure 32bit x86:

push edi
pop edi

Well, this program runs ok in win NT or win 2000.
So, the question is: if those instructions are not recognized by a 64bit x86 CPU, why the hell it runs in a windows 10 x64?

[Rinzwind]

Because the cpu too has a 32 bit mode. A search would give you that answer too.
https://en.wikipedia.org/wiki/X86-64

[Psychophanta]

Because the cpu too has a 32 bit mode. A search would give you that answer too.
https://en.wikipedia.org/wiki/X86-64

If it is the case, i.e., if the cpu has 32 bit mode, then ¿why PB x64 is not able to allow those instructions?

[Rinzwind]

It is if you use 32 bit PB

[Denis]

It's not a PB problem.

Rinzwind is right.
it's a CPU plateform limitation.

You compile in 32 bit mode, so PUSH/POP EDI is correct (RDI doesn't exist in 32 bit).
You compile in 64 bit mode (so compiler 64 not compiler 32), so PUSH/POP EDI is not correct.

There is no problem to run a 32 bit exe under windows 64 bit version, in that case register will be edi due the fact that your are not in 64-bit mode .

[Psychophanta]

Aha, then there is compiler (or general app) what tell the system if it is a 64bit or 32bit program.
Is is a issue of the ugly CPU architecture, and then, the O.S. policies adapted to it.

Thanks.

[Mijikai]

...
Is is a issue of the ugly CPU architecture, and then, the O.S. policies adapted to it.
...

Its not an issue thats why you are able to run x86 assembly on an x64 cpu.
If you compile to x86 the code will work as usual no changes needed.
(Imho. thats why it is important for PB to support x86.)

The compiler takes care of the context switching between x86 and x64.
U can mix x86 and x64 assembly but then u need to perform context switching manually which is not trivial.

[Psychophanta]

...
Is is a issue of the ugly CPU architecture, and then, the O.S. policies adapted to it.
...

Its not an issue thats why you are able to run x86 assembly on an x64 cpu.
If you compile to x86 the code will work as usual no changes needed.
(Imho. thats why it is important for PB to support x86.)

The compiler takes care of the context switching between x86 and x64.
U can mix x86 and x64 assembly but then u need to perform context switching manually which is not trivial.

Ok, but clearly it is an ugly stupid issue, since I can do a 16bit code like:

Code: Select all

!push di
!pop di

in any 32bit windows, without need to do nothing more, neither any special tasks.

BUT can not be done:

Code: Select all

!push edi
!pop edi

in a 64bit windows.

So , that is what is called ugly incoherent issue.
Lets be honest, please.

[Olli]

The ASM syntax has already been debated on C fora and, the way to keep hardware compatibility (ARM vs Intel) is found since long time on C.

Fred approached it on Version 6, so the ASM syntax has changed.

[Olli]

Code: Select all

; fsincos in C Backend
Define rcos.f, rsin.f, angle.f=3.141
! asm volatile("fsincos" : "=%&t" (v_rcos), "=%&u" (v_rsin) : "0" (v_angle));
SetClipboardText(StrF(rsin)+" "+StrF(rcos))
; 0.0005926211 -0.9999998212

@juergenkulow

How are defined 'u' and 't' ? Have you a link to a documentation about what these characters are referring ?

Other question about my remark : am I wrong about the crossplatform aspect between ARM and Intel standard ? In an other way, is your code adapted to ARM too, as I am supposing ?

Thank you in advance.

[juergenkulow]

https://gcc.gnu.org/onlinedocs/gcc.pdf Page 706 (690)

Code: Select all

; fsincos in C Backend and ASM 
Define rcos.f, rsin.f, angle.f=3.141
CompilerIf #PB_Processor_x64=#PB_Compiler_Processor Or #PB_Processor_x86=#PB_Compiler_Processor
  CompilerIf Defined(PB_Backend_C,#PB_Constant) 
    CompilerIf #PB_Compiler_Backend=#PB_Backend_C
      ! asm volatile("fsincos" : "=%&t" (v_rcos), "=%&u" (v_rsin) : "0" (v_angle));
    CompilerElse ;#PB_Backend_ASM
      EnableASM 
      FLD    dword [v_angle]
      FSINCOS
      FSTP   dword [v_rcos] 
      FSTP   dword [v_rsin]
      DisableASM
    CompilerEndIf
  CompilerElse ; PB < 6.00
    EnableASM 
    FLD    dword [v_angle]
    FSINCOS
    FSTP   dword [v_rcos] 
    FSTP   dword [v_rsin]  
    DisableASM
  CompilerEndIf
CompilerElse ; other Processor
  rcos=Cos(angle)
  rsin=Sin(angle)   
CompilerEndIf
SetClipboardText(StrF(rsin)+" "+StrF(rcos))
; 0.0005926211 -0.9999998212

ARM M1 Microarchitecture Firestorml
https://developer.arm.com/documentation/ddi0487/gb/

[Olli]

@juergenkulow

To conclude, after having read the docs you provided, is I am wrong about ARM : I do not see an ARM fsincos equivalent.

I note fSinCos is an x86/x64 ASM example which finds crossplatform (this time, for ARM too) libraries, faster than hardware co-processor. But this goes away from the initial subject.

Thank you for the detailed source code.