Page 1 of 1
Strange problem with labels
Posted: Sat Aug 20, 2016 5:34 pm
by doctorized
If I say:
Code: Select all
aa.l
EnableASM
mov eax, 1
cmp eax, 1
je l_nxt
mov eax, 5
nxt:
mov aa, eax
DisableASM
Debug aa
I get output 1 as expected but if I say:
Code: Select all
Procedure test()
aa.l
EnableASM
mov eax, 1
cmp eax, 1
je l_nxt
mov eax, 5
nxt:
mov aa, eax
DisableASM
Debug aa
EndProcedure
test()
I get undefined symbol 'l_nxt' error. Why? What is the right expression?
Re: Strange problem with labels
Posted: Sat Aug 20, 2016 5:54 pm
by Shield
If the label is defined in a procedure, then its prefix is 'l_procedurename_', in lowercase.
Manual is actually wrong here, it should be ll_:
Code: Select all
Procedure test()
aa.l
EnableASM
mov eax, 1
cmp eax, 1
je ll_test_nxt
mov eax, 5
nxt:
mov aa, eax
DisableASM
Debug aa
EndProcedure
test()
Re: Strange problem with labels
Posted: Sat Aug 20, 2016 6:27 pm
by Keya
another option is to !inline them directly to the assembler:
Code: Select all
aa.l
EnableASM
mov eax, 1
cmp eax, 1
!je nxt ;<--
mov eax, 5
!nxt: ;<--
mov aa, eax
DisableASM
Debug aa
Re: Strange problem with labels
Posted: Sat Aug 20, 2016 6:47 pm
by doctorized
Thanx for the replies. I had tried ll_ but I didn't know that procedure name should be included.
Re: Strange problem with labels
Posted: Sat Aug 20, 2016 7:29 pm
by wilbert
Personally I prefer the inline approach Keya demonstrated.
As far as I remember, the way labels are named hasn't always been the same across different PB versions.
It also looks inconsistent to me that the label you have to use for the jump instruction is different form the label declaration itself.
By coding manually, I have full control and know things are working as they should.
Re: Strange problem with labels
Posted: Sat Aug 20, 2016 9:19 pm
by doctorized
wilbert wrote:Personally I prefer the inline approach Keya demonstrated.
As far as I remember, the way labels are named hasn't always been the same across different PB versions.
It also looks inconsistent to me that the label you have to use for the jump instruction is different form the label declaration itself.
By coding manually, I have full control and know things are working as they should.
Yes, you are right. The way labels work in asm have changed at least two times the last years. I would like to have something more "stable", something that will last regardless PB changes. Is Keya's approach this kind of "stable"?
Re: Strange problem with labels
Posted: Sat Aug 20, 2016 11:08 pm
by Helle
We hope so
!
In procedures use label with point as local label. See:
Code: Select all
Procedure test()
aa.l
EnableASM
mov eax, 1
cmp eax, 1
!je nxt
mov eax, 5
!nxt:
mov aa, eax
DisableASM
Debug aa
EndProcedure
Procedure test1()
aa.l
EnableASM
mov eax, 1
cmp eax, 1
!je nxt
mov eax, 5
!nxt:
mov aa, eax
DisableASM
Debug aa
EndProcedure
test()
test1()
But:
Code: Select all
Procedure test()
aa.l
EnableASM
mov eax, 1
cmp eax, 1
!je .nxt
mov eax, 5
!.nxt:
mov aa, eax
DisableASM
Debug aa
EndProcedure
Procedure test1()
aa.l
EnableASM
mov eax, 1
cmp eax, 1
!je .nxt
mov eax, 5
!.nxt:
mov aa, eax
DisableASM
Debug aa
EndProcedure
test()
test1()
Re: Strange problem with labels
Posted: Sun Aug 21, 2016 9:54 am
by Shield
If it's just about one or two local labels, I prefer using anonymous labels:
Code: Select all
Procedure.i foobar()
!jmp @f
MessageRequester("skip", "skip")
!@@:
ProcedureReturn 0
EndProcedure
foobar()
Use @f to jump forward or @b to jump backwards.
Re: Strange problem with labels
Posted: Sun Aug 21, 2016 11:02 am
by sys64802
Yes the fact you must decorate your labels it's clunky, particularly inside EnableASM/DisableASM
request
http://www.purebasic.fr/english/viewtop ... 56#p451756
Are anon labels available on mac too ? Don't know if nasm or yasm is used on mac, but in any case I'm not sure if anon labels are supported there.
Re: Strange problem with labels
Posted: Sun Aug 21, 2016 11:15 am
by wilbert
The dot syntax Helle mentioned seems to work fine on OSX.
Anonymous labels (@f with @@) are not supported on OSX. Nasm/Yasm doesn't support this.
If you want your Asm code to be cross platform compatible, don't use them.
Re: Strange problem with labels
Posted: Sun Aug 21, 2016 11:26 am
by sys64802
wilbert wrote:
Anonymous labels (@f with @@) are not supported on OSX. Nasm/Yasm doesn't support this.
Thank you, but out of curiosity it's nasm or yasm used on osx ?
Re: Strange problem with labels
Posted: Sun Aug 21, 2016 12:15 pm
by wilbert
sys64802 wrote:Thank you, but out of curiosity it's nasm or yasm used on osx ?
Both
PureBasic uses yasm for the 64 bit version of PureBasic on OSX and nasm for the 32 bit version.
Don't ask me why because I have no idea why Fred made this choice.
To me it would be more logical to choose one of the two and use it for both 32 and 64 bit.
Edit:
It seems also possible to use Fasm on OSX with the help of the objconv tool from Agner Fog.
http://www.agner.org/optimize/objconv-instructions.pdf
https://github.com/JohnDDuncanIII/fasm-osx
Re: Strange problem with labels
Posted: Sun Aug 21, 2016 12:48 pm
by sys64802
Thank you.
Didn't know about objconv, that guy is crazy. Awesome. But I don't know enough to fully understand the limitations I think. Way over my head.
Still awesome from what I can understand.
Re: Strange problem with labels
Posted: Sun Aug 21, 2016 1:41 pm
by doctorized
sys64802 wrote:Thank you.
Didn't know about objconv, that guy is crazy. Awesome. But I don't know enough to fully understand the limitations I think. Way over my head.
Still awesome from what I can understand.
What's the awesome?
What's objconv?
Re: Strange problem with labels
Posted: Mon Mar 12, 2018 11:17 pm
by Tristano
There have also been around Mac ports of FAsm. Here is one:
https://github.com/JohnDDuncanIII/fasm
the repository contains a flat assembler version that will run on Macintosh OS X 10.6-10.11 (both x86 and x86_64).
Even though this isn't an officially supported FAsm version, and won't be guaranteed to be always updated along with latest official FAsm releases, it would be nice if in the upcoming PureBasic versions there was an option to use the FAsm compiler on Mac, instead of Yasm/MASM. I wonder if this is possible ...
If Mac where to support FAsm then there would no longer be the cross-compatiblity issue that is currently introduced by the presence of ASM code in PB sources.