how to rewrite particular asm inline syntax for gcc?

[wawa]

hi guys. im noob in c/c++, but im completely unaware of assembler. what i need to do, is to rewrite particular 68k asm inlines not understood by gcc4-6 compilers. the exemplary line in question is:
1: bset.b #0,4(a1)\n

code below:

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: bset.b #0,4(a1)\n"
" bne.b 1b\n"
"2: move.l (a1),(a0)\n"
" move.l a0,(a1)\n"
" bclr.b #0,4(a1)\n"
:
: "m" (item), "m" (list)
: "a0", "a1", "cc", "memory"
);
}

btw, if there is any handy guide, including different dialects of syntax to translate, you could point me to, id be grateful.

[Apollo]

Originally Posted by wawa

1: bset.b #0,4(a1)\n

Maybe he just chokes on the size operand? Does it assemble withe size operand omitted?

[wawa]

nope.

what has helped was to convert
"1: bset.b #0,4(a1)\n"
to
"1: bset.b #0,4(%%a1)\n"

which is curious, because i had only to change it in both cases of bset.b and bclr.b the assembler was complaining about, leaving all the other instructions syntax alone.

[arti]

hi, like wawa "im noob in c/c++, but im completely unaware of assembler"
and would like to use this crc32 algorithm in libz to speedup png decoding in netsurf.

Basicaly i want to use this

;1. AmigaOS and AsmOne
;2. should be equal to LHA, LZX and so on
;3. no warranty of any kind is given
;4. further optimisations are very welcome
;

	;bsr	MakeCRC32Tab
	;rept 20
	;lea.l	$f80000,a0
	;move.l	#512000,d2
	;bsr	CalcCRC32
	;endr
	rts


	cnop	0,4
CalcCRC32:

	;a0 - buffer
	;d2 - size

	addq.l	#1,d2

	moveq	#0,d7
	not.b	d7

	lea.l	CRC32tab,a3
	move.l	#$EDB88320,d4			;classic

	move.l	a0,a5
	bra.s	.A

	cnop	0,4
.loop:
	moveq	#0,d1
	move.b	(a5)+,d1

	move.l	d4,d0
	eor.l	d1,d4
	and.l	d7,d4
	
	lsl.l	#2,d4				;for 020+ shortens to
	move.l	(a3,d4.L),d4			;move.l	(a3,d4.L*4),d4

	lsr.l	#8,d0
	eor.l	d0,d4
.A:
	subq.l	#1,d2
	bne.b	.loop

	move.l	d4,d0
	rts


	cnop	0,4
MakeCRC32Tab:
	move.l	#$100,d4
	lea.l	$EDB88320,a3			;classic
	lea.l	CRC32tab(pc),a0
	moveq	#0,d1
.A
	move.l	d1,d6
	moveq	#0,d5
.B
	move.l	d6,d0
	lsr.l	#1,d0
	btst	#0,d6
	beq.s	.C
	move.l	a3,d6
	eor.l	d0,d6
	bra.b	.D

	cnop	0,4

.C	move.l	d0,d6
.D
	addq.l	#1,d5
	moveq	#8,d0
	cmp.l	d0,d5
	bcs.s	.B
	addq.l	#1,d1
	
	move.l	d6,(a0)+
	cmp.l	d4,d1
	bcs.s	.A
	rts

CRC32tab:	ds.b	1024

instead of this:

static mz_uint32 poly_table[256];
mz_ulong mz_crc32(mz_ulong crc, const mz_uint8 *ptr, size_t buf_len)
{
  // Generate the poly table on first use.
  // This should match what mhash calls `crc32_table_b`
  if (!poly_table[1]) {
    mz_uint32 i, j;
    for (i = 0; i < 256; i++) {
      mz_uint32 entry = i;
      for (j = 0; j < 8; j++) {
        if (entry & 1) entry = (entry >> 1) ^ 0xedb88320;
        else entry >>= 1;
      }
      poly_table[i] = entry;
    }
  }
 
  crc = ~crc;
  while (buf_len--) {
    crc = ((crc >> 8) & 0xffffff) ^ poly_table[(*ptr++ ^ crc) & 0xff];
  }
  return ~crc;
}

I assume
mz_crc32(mz_ulong crc(?), const mz_uint8 *ptr(A0 here?), size_t buf_len (d2 here?))

but how about crc ? ^

[meynaf]

Originally Posted by arti

and would like to use this crc32 algorithm in libz to speedup png decoding in netsurf.

Simple : drop crc computation completely. Showing a png doesn't need crc checking.

[arti]

You mean:

mz_ulong mz_crc32(mz_ulong crc, const mz_uint8 *ptr, size_t buf_len)
{
  return crc;
}

This gives CRC error.

[meynaf]

Originally Posted by arti

You mean:

mz_ulong mz_crc32(mz_ulong crc, const mz_uint8 *ptr, size_t buf_len)
{
  return crc;
}

This gives CRC error.

No, i mean not even calling that function and not checking crc result at all. Look where this function is called, not the function itself.

[wawa]

Originally Posted by Apollo

Maybe he just chokes on the size operand? Does it assemble withe size operand omitted?

..long time gone, i applied probably wrong fix, back on it..

like
"1: bset.b #0,4(a1)\n"
>
"1: bset.b #0,(a1)\n"

if so, yes it works. doesnt the size of operand matter something?
i still get the same runtime error, so apparently this is not the issue, but it assembles with relatively slight change in comparison to original source.

[Galahad/FLT]

Originally Posted by wawa

..long time gone, i applied probably wrong fix, back on it..

like
"1: bset.b #0,4(a1)\n"
>
"1: bset.b #0,(a1)\n"

if so, yes it works. doesnt the size of operand matter something?
i still get the same runtime error, so apparently this is not the issue, but it assembles with relatively slight change in comparison to original source.

you can't do that, because that instruction is doing a bitset on the contents of A0 + 4, later in that routine of yours it does a BCLR to the same offset.

Its not having issues because of the 1: is it?

[LaBodilsen]

I don't know any C/C++, but assembler.
Maybe it dont like offsets being written as 4(a1), but need it as (4,a1). Resource Disassembler writes it like that, and both methods work in Asm-pro.

so:

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: bset.b #0,(4,a1)\n"
" bne.b 1b\n"
"2: move.l (a1),(a0)\n"
" move.l a0,(a1)\n"
" bclr.b #0,(4,a1)\n"
:
: "m" (item), "m" (list)
: "a0", "a1", "cc", "memory"
);
}

[wawa]

Originally Posted by Galahad/FLT

Its not having issues because of the 1: is it?

Apparently Not. and your method doesnt help.

once upon a time i "fixed" it like this:

  asm volatile("   move.l %0,%%a0\n"
                "   move.l %1,%%a1\n"
                "1: bset.b #0,4(%%a1)\n"
                "   bne.b 1b\n"
                "2: move.l (%%a1),(%%a0)\n"
                "   move.l %%a0,(%%a1)\n"
                "   bclr.b #0,4(%%a1)\n"
                :
                : "m" (item), "m" (list)
                : "a0", "a1", "cc", "memory"

it assembles, but i dont know if it actually works. have a feeling it might not.

[LaBodilsen]

Dont think %%A1 will work.
from here: https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html

Special format strings
In addition to the tokens described by the input, output, and goto operands, these tokens have special meanings in the assembler template:

‘%%’
Outputs a single ‘%’ into the assembler code.

But looking at the assembly code, and if it fails to compile offsets for address registers.

then this: "1: bset.b #0,4(a1)\n"

would be the same as: "1: bset.l #0,(a1)\n"
(only a little slower)

so maybe this will work:

removed

btw: if you want the Assembly code translated to something readable, that you can implement in C, let us now. I think it would be easy to create some psydo-code out if these few lines.

[meynaf]

Originally Posted by LaBodilsen

then this: "1: bset.b #0,4(a1)\n"

would be the same as: "1: bset.l #0,(a1)\n"
(only a little slower)

Should be 3(a1) rather than 4(a1) in the above code, but anyway bset has no size. Assemblers can eventually accept bset.b because the target is always bytes, but everything else is plain wrong (and can easily lead to faulty code).

[LaBodilsen]

Originally Posted by meynaf

Should be 3(a1) rather than 4(a1) in the above code, but anyway bset has no size. Assemblers can eventually accept bset.b because the target is always bytes, but everything else is plain wrong (and can easily lead to faulty code).

You are ofcourse right (need more coffee).

Only when adressing a Data register direct, is the size Long, all else is byte size.

previous post "scrambled"

[wawa]

ok, guys, are you telling me that this assembly code is wrong anyway? and that "bset.b" should actually be "bset"?

i have made a c testcase source:

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: bset.b #0,4(a1)\n"
                "   bne.b 1b\n"
                "2: move.l (a1),(a0)\n"
                "   move.l a0,(a1)\n"
                "   bclr.b #0,4(a1)\n"
                :
                : "m" (item), "m" (list)
                : "a0", "a1", "cc", "memory"
         );
}

plainly invoked with no flags both aros compilers i use and bebbos 6.3 are fine about this code. aros-4.6.4 complains about no "main" function, but both aros-6.3.0 and bebbos one have even built me a binary with few warnings.

perhaps it is some compile flag on aros part, perhaps pedantic.

so, if the code is wrong, can i ask you guys to correct it? there are just few 68k inlines here in frying pan source.

[LaBodilsen]

It's only wrong in the sence that bset is always byte size, so no need to set .b on it.

But if it compiles fine with bset.b #0,(a1), then this is not the problem. but i suspect that it have a problem with the way that offsets are written. eg 4(a1). did you try it with bset.b #0,(4,a1) instead?

[wawa]

Yes,i tried it, but it didnt help.

[meynaf]

Of course it will not help if the offset is wrong.
Again, last byte of a long is +3, not +4 (offsets are 0, +1, +2, +3, total 4 bytes).
+4 is first byte of next long.

[wawa]

but the assembler shouldnt complain about that (syntax), just the code wouldnt work, am i rght? so:

bset.b #0,4(a1)\n

translates to:

bset #0,(3,a1)\n

?

[meynaf]

For the assembler there should be no difference between :

bset #0,3(a1)
bset #0,(3,a1)
bset.b #0,3(a1)
bset.b #0,(3,a1)

3(a1) vs (3,a1) is simply 68000 vs 68020 syntax. And no, 4 doesn't translate to 3
bset is same as bset.b because it has no size.

Then perhaps some assemblers will accept one form and reject another.

But if your code assembles with no error and the resulting code doesn't work, then there is a bug to be fetched elsewhere in the program.