how to rewrite particular asm inline syntax for gcc? - Page 2

wawa · 08 February 2018, 17:47

ok, so basically nothing is wrong with the code, as expected and it should work with gcc, which it does as isolated testcase. remains to be seen why it doesnt when inlined from a c header. need to check further. compile flags seem of no effect, for most part at least.

wawa · 08 February 2018, 21:27

okay, i have the feeling that it is not actually an asm syntax problem but a problem with an include that declares int32, because no matter presence of bset, the problems only appear in inlines that contain an int32 format argument.

wawa · 11 February 2018, 20:37

sorry that im so thick but i must ask again, because id dont find actually a reference to such a construct on the net. according to
http://mrjester.hapisan.com/04_MC68/...t05/Index.html
bset may actually be byte or long, so:
bset.b #0,4(a1)

means to set a fist bit ($00) of a byte in memory pointed to by addition of the content of address register with an offset 4. perhaps the compiler in question doesnt understand relative addressing (if this is the right word?) since it doenst complain about things like
bset.b #7,(a0)
futher down in code.
is it possible to substitute
bset.b #0,4(a1)
like this:
addi.b #4,a1
bset.b #0,(a1)

..or something similar?

ross · 11 February 2018, 21:16

Yes, it's only slower (on pure 68k):

Code:

	addq.l	#4,a1		;5889 		-  8 cycles ;addi.b does not exists
	bset	#0,(a1)		;08d10000	- 16 cycles
	
	bset	#0,4(a1)	;08e900000004	- 20 cycles

meynaf · 11 February 2018, 21:18

Quote:

Originally Posted by wawa

sorry that im so thick but i must ask again, because id dont find actually a reference to such a construct on the net. according to
http://mrjester.hapisan.com/04_MC68/...t05/Index.html
bset may actually be byte or long, so:
bset.b #0,4(a1)

It is byte if targeting memory, long if targeting register.
Again, size spec here is useless.

Quote:

Originally Posted by wawa

means to set a fist bit ($00) of a byte in memory pointed to by addition of the content of address register with an offset 4. perhaps the compiler in question doesnt understand relative addressing (if this is the right word?) since it doenst complain about things like
bset.b #7,(a0)
futher down in code.

Why would it complain about that ? It's perfectly valid.

Quote:

Originally Posted by wawa

is it possible to substitute
bset.b #0,4(a1)
like this:
addi.b #4,a1
bset.b #0,(a1)

..or something similar?

Well, with addi.b to a1 you can be sure the asm, this time, will complain

What you want to do here would just make the program waste time and space anyway.

wawa · 11 February 2018, 22:21

Quote:

Originally Posted by meynaf

Why would it complain about that ? It's perfectly valid.

i dont know, but it does:

Quote:

/tmp/cc7mMMJl.s: Assembler messages:
/tmp/cc7mMMJl.s:32: Error: syntax error -- statement `bset.b #0,4(a1)' ignored
/tmp/cc7mMMJl.s:32: Error: syntax error -- statement `bclr.b #0,4(a1)' ignored
/tmp/cc7mMMJl.s:92: Error: syntax error -- statement `bset.b #0,4(a1)' ignored
/tmp/cc7mMMJl.s:92: Error: syntax error -- statement `bclr.b #0,4(a1)' ignored
/tmp/cc7mMMJl.s:280: Error: syntax error -- statement `bset.b #0,4(a1)' ignored
/tmp/cc7mMMJl.s:280: Error: syntax error -- statement `bclr.b #0,4(a1)' ignored

while the code proposed by ross gets accepted. yes, the speed penalty should be considered, i guess even is 20 vs 24 cycles doesnt sound a lot. this is an own implementation of slab memory allocator so far is see.

Don_Adan · 12 February 2018, 03:34

Quote:

Originally Posted by ross

Yes, it's only slower (on pure 68k):

Code:

	addq.l	#4,a1		;5889 		-  8 cycles ;addi.b does not exists
	bset	#0,(a1)		;08d10000	- 16 cycles
	
	bset	#0,4(a1)	;08e900000004	- 20 cycles

Yes, but this is valid only if A1 is unused later. Or subq.l #4,A1 must be added too.
I almost forget 68k assembler, but why he dont use:
or.b #1, 4(a1) as bset #0,4(a1)
and.b #$FE,4(a1) as bclr #0,4(a1)

LaBodilsen · 12 February 2018, 08:21

Maybe you should try and isolate what it is it dont like. eg, if it's only the address mode 4(a1), or something else.

how do something like this compile (don't run it, only compile):

Code:

static inline void _atomic_stack_push(struct _atomic_stack* list, struct _atomic_item* item)
{
asm volatile(
"move.b #0,4(a1)\n"
"move.b #0,(a1)\n"
"move.w #0,4(a1)\n"
"move.w #0,(a1)\n"
"move.l #0,4(a1)\n"
"move.l #0,(a1)\n"
"bset #0,4(a1)\n"
"bset #0,(a1)\n"
"bclr #0,4(a1)\n"
"bclr #0,(a1)\n"
:
: "m" (item), "m" (list)
: "a1", "cc", "memory"
);
}

what errors do you get? if you only get errors on lines with 4(a1), i think it would be safe to assume that the problem is in the addressing with offsets.

a workaround could then maybe be to use the opcode instead, and have the assembler translate that instead of the mnemonic:

bset #0,4(a1) = dc.w $08e9,$0000,$0004

another solution is to use the suggested add/sub

Code:

addq.l #4,a1
bset #0,(a1)
subq.l #4,a1

Be aware though, that this might not trigger the branch correctly:
bne.b 1b >meynaf to the resque, the branch is not affected by addq/subq

meynaf · 12 February 2018, 08:58

Quote:

Originally Posted by LaBodilsen

Be aware though, that this might not trigger the branch correctly:
bne.b 1b

No problem here, ADDQ/SUBQ to address registers do not touch the CC so the branch will be correct.

LaBodilsen · 12 February 2018, 09:25

Quote:

Originally Posted by meynaf

No problem here, ADDQ/SUBQ to address registers do not touch the CC so the branch will be correct.

Thank you for the information, much appreciated.

wawa · 12 February 2018, 11:13

Quote:

Originally Posted by LaBodilsen

how do something like this compile (don't run it, only compile):

Code:

static inline void _atomic_stack_push(struct _atomic_stack* list, struct _atomic_item* item)
{
asm volatile(
"move.b #0,4(a1)\n"
"move.b #0,(a1)\n"
"move.w #0,4(a1)\n"
"move.w #0,(a1)\n"
"move.l #0,4(a1)\n"
"move.l #0,(a1)\n"
"bset #0,4(a1)\n"
"bset #0,(a1)\n"
"bclr #0,4(a1)\n"
"bclr #0,(a1)\n"
:
: "m" (item), "m" (list)
: "a1", "cc", "memory"
);
}

what errors do you get?

Quote:

/tmp/ccpUi2Rs.s:8: Error: syntax error -- statement `move.b #0,4(a1)' ignored
/tmp/ccpUi2Rs.s:8: Error: syntax error -- statement `move.w #0,4(a1)' ignored
/tmp/ccpUi2Rs.s:8: Error: syntax error -- statement `move.l #0,4(a1)' ignored
/tmp/ccpUi2Rs.s:8: Error: syntax error -- statement `bset #0,4(a1)' ignored
/tmp/ccpUi2Rs.s:8: Error: syntax error -- statement `bclr #0,4(a1)' ignored

so its obvious that the compiler doesnt get along the addressing mode. perhaps i need to ask bebbo how he has enabled it with his gcc.

meynaf · 12 February 2018, 11:21

How does it react with this :

Code:

 move.b #0,(4,a1)

Rejected or not ?

ross · 12 February 2018, 11:36

Just a doubt..
It is not that AT&T (GAS) syntax should be used?

EDIT: something like

bset #0,%a1@(4)

StingRay · 12 February 2018, 13:24

If everything fails you could still use the hex opcode for the instructions the compiler doesn't like. bset #0,4(a1) would be $08e9 0000 0004

LaBodilsen · 12 February 2018, 13:39

Quote:

Originally Posted by ross

Just a doubt..
It is not that AT&T (GAS) syntax should be used?

EDIT: something like

bset #0,%a1@(4)

You might be onto something here. but should not all reference to a1 be %a1 then?

I'm purely speculating here, but Wawa, do you compile with the -mgas parameter set, or with -malpha-as?

LaBodilsen · 12 February 2018, 13:45

Quote:

Originally Posted by StingRay

If everything fails you could still use the hex opcode for the instructions the compiler doesn't like. bset #0,4(a1) would be $08e9 0000 0004

and for bclr #0,4(a1) would be $0889, $0000, $0004

and the code would be:

Code:

static inline void _atomic_stack_push(struct _atomic_stack* list, struct _atomic_item* item)
{
asm volatile(" move.l %0,a0\n"
" move.l %1,a1\n"
"1: dc.w $08e9,$0000,$0004\n"
" bne.b 1b\n"
"2: move.l (a1),(a0)\n"
" move.l a0,(a1)\n"
" dc.w  $0889,$0000,$0004\n"
:
: "m" (item), "m" (list)
: "a0", "a1", "cc", "memory"
);
}

meynaf · 12 February 2018, 14:01

The asm may well be rejecting dc.w directives too

wawa · 12 February 2018, 19:50

Quote:

Originally Posted by meynaf

How does it react with this :

Code:

 move.b #0,(4,a1)

Rejected or not ?

rejected as well.

but dc.w and with hex opcode compiled perfectly.

wawa · 12 February 2018, 19:56

Quote:

Originally Posted by LaBodilsen

You might be onto something here. but should not all reference to a1 be %a1 then?

exactly. that was the firrst thing i was pointed to, but it doesnt seem to be generally a problem here.

Quote:

I'm purely speculating here, but Wawa, do you compile with the -mgas parameter set, or with -malpha-as?

not intentionally. the build system delivers all the common flags except particularly specified with the makefile, but the whole invocation for source file that gets asm inlines is like follows:

Quote:

Compile failed: /home/wawa/aros-m68k-464/bin/linux-i386/tools/crosstools/m68k-aros-gcc -iquote /home/wawa/AROS-source/AROS/contrib/FryingPan/framework/LibC/./ -iquote /home/wawa/AROS-source/AROS/contrib/FryingPan/framework/LibC -iquote . -O2 -Os -DAROS_BUILD_TYPE=AROS_BUILD_TYPE_PERSONAL -fno-strict-aliasing -ffreestanding -fomit-frame-pointer -fbuiltin -DNOLIBINLINE -Wall -Werror -Wno-pointer-sign -Wno-parentheses -Wno-volatile-register-var -m68020 -isystem /home/wawa/AROS-source/AROS/contrib/FryingPan/framework/LibC/.. -D__SRCFILENAME__="contrib/FryingPan/framework/LibC/slab.c" -c /home/wawa/AROS-source/AROS/contrib/FryingPan/framework/LibC/./slab.c -o /home/wawa/aros-m68k-464/bin/amiga-m68k/gen/contrib/FryingPan/framework/LibC/slab.o
/tmp/ccyALFgv.s: Assembler messages:

bebbo · 12 February 2018, 23:50

since you asked in a different thread and pointet to this one:

I am not aware of a special change, since those statements used to work. I grabbed my first cross compiler tries, searched and found something which might help you:

Code:

configure  --prefix=/cygdrive/d/cross620 --target=m68k-amigaos --program-prefix=m68k-amigaos-
...
xbu-2.14/gas/as-new.exe orb.s -o orb.o

is working

Code:

configure  --prefix=/cygdrive/d/cross620e --target=m68k-elf --program-prefix=m68k-elf-

xbu-2.14e/gas/as-new.exe orb.s -o orb.o

is not working.

=> The configuration for elf sets something which causes this behaviour.

no clue what it might be.

PS: compile into the amiga hunk format then use a hunk2elf converter^^

11 February 2018, 21:16	#24
ross Defendit numerus Join Date: Mar 2017 Location: Crossing the Rubicon Age: 53 Posts: 4,468	Yes, it's only slower (on pure 68k): Code: addq.l #4,a1 ;5889 - 8 cycles ;addi.b does not exists bset #0,(a1) ;08d10000 - 16 cycles bset #0,4(a1) ;08e900000004 - 20 cycles

12 February 2018, 08:21	#28
LaBodilsen Registered User Join Date: Dec 2017 Location: Denmark Posts: 179	Maybe you should try and isolate what it is it dont like. eg, if it's only the address mode 4(a1), or something else. how do something like this compile (don't run it, only compile): Code: static inline void _atomic_stack_push(struct _atomic_stack* list, struct _atomic_item* item) { asm volatile( "move.b #0,4(a1)\n" "move.b #0,(a1)\n" "move.w #0,4(a1)\n" "move.w #0,(a1)\n" "move.l #0,4(a1)\n" "move.l #0,(a1)\n" "bset #0,4(a1)\n" "bset #0,(a1)\n" "bclr #0,4(a1)\n" "bclr #0,(a1)\n" : : "m" (item), "m" (list) : "a1", "cc", "memory" ); } what errors do you get? if you only get errors on lines with 4(a1), i think it would be safe to assume that the problem is in the addressing with offsets. a workaround could then maybe be to use the opcode instead, and have the assembler translate that instead of the mnemonic: bset #0,4(a1) = dc.w $08e9,$0000,$0004 another solution is to use the suggested add/sub Code: addq.l #4,a1 bset #0,(a1) subq.l #4,a1 Be aware though, that this might not trigger the branch correctly: bne.b 1b >meynaf to the resque, the branch is not affected by addq/subq Last edited by LaBodilsen; 12 February 2018 at 09:36. Reason: Changed the code segment.

12 February 2018, 11:21	#32
meynaf son of 68k Join Date: Nov 2007 Location: Lyon / France Age: 51 Posts: 5,322	How does it react with this : Code: move.b #0,(4,a1) Rejected or not ?

12 February 2018, 11:36	#33
ross Defendit numerus Join Date: Mar 2017 Location: Crossing the Rubicon Age: 53 Posts: 4,468	Just a doubt.. It is not that AT&T (GAS) syntax should be used? EDIT: something like bset #0,%a1@(4) Last edited by ross; 12 February 2018 at 11:42. Reason: gas tentative..

12 February 2018, 23:50	#40
bebbo bye Join Date: Jun 2016 Location: Some / Where Posts: 680	since you asked in a different thread and pointet to this one: I am not aware of a special change, since those statements used to work. I grabbed my first cross compiler tries, searched and found something which might help you: Code: configure --prefix=/cygdrive/d/cross620 --target=m68k-amigaos --program-prefix=m68k-amigaos- ... xbu-2.14/gas/as-new.exe orb.s -o orb.o is working Code: configure --prefix=/cygdrive/d/cross620e --target=m68k-elf --program-prefix=m68k-elf- xbu-2.14e/gas/as-new.exe orb.s -o orb.o is not working. => The configuration for elf sets something which causes this behaviour. no clue what it might be. PS: compile into the amiga hunk format then use a hunk2elf converter^^

08 February 2018, 17:47	#21
wawa Registered User Join Date: Aug 2007 Location: berlin/germany Posts: 1,054	ok, so basically nothing is wrong with the code, as expected and it should work with gcc, which it does as isolated testcase. remains to be seen why it doesnt when inlined from a c header. need to check further. compile flags seem of no effect, for most part at least.

08 February 2018, 21:27	#22
wawa Registered User Join Date: Aug 2007 Location: berlin/germany Posts: 1,054	okay, i have the feeling that it is not actually an asm syntax problem but a problem with an include that declares int32, because no matter presence of bset, the problems only appear in inlines that contain an int32 format argument.

11 February 2018, 20:37	#23
wawa Registered User Join Date: Aug 2007 Location: berlin/germany Posts: 1,054	sorry that im so thick but i must ask again, because id dont find actually a reference to such a construct on the net. according to http://mrjester.hapisan.com/04_MC68/...t05/Index.html bset may actually be byte or long, so: bset.b #0,4(a1) means to set a fist bit ($00) of a byte in memory pointed to by addition of the content of address register with an offset 4. perhaps the compiler in question doesnt understand relative addressing (if this is the right word?) since it doenst complain about things like bset.b #7,(a0) futher down in code. is it possible to substitute bset.b #0,4(a1) like this: addi.b #4,a1 bset.b #0,(a1) ..or something similar?

12 February 2018, 13:24	#34
StingRay move.l #$c0ff33,throat Join Date: Dec 2005 Location: Berlin/Joymoney Posts: 6,863	If everything fails you could still use the hex opcode for the instructions the compiler doesn't like. bset #0,4(a1) would be $08e9 0000 0004

12 February 2018, 14:01	#37
meynaf son of 68k Join Date: Nov 2007 Location: Lyon / France Age: 51 Posts: 5,322	The asm may well be rejecting dc.w directives too

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Tool to convert asm to gnu asm (gas)	Asman	Coders. Asm / Hardware	13	30 December 2020 11:57
Inline ASM	xArtx	Coders. Asm / Hardware	10	27 July 2014 16:21
XAMOS - new cross-platform rewrite of jAMOS	Mequa	News	24	14 December 2012 09:49
Storm C V4...using inline assembler	NovaCoder	Coders. General	11	26 February 2009 12:10
Syntax Error in IE.	Fred the Fop	project.EAB	2	04 October 2002 14:47