pouët.net

I've been reading the GAS manual but haven't found a solution for this yet. I've got a program that outputs a bunch of data as an .s file. It contains several tables like this:

top_label:
.dw label_a
.dw label_b
.dw label_c

The file is then assembled with GAS and linked into a ROM. At runtime, a co-processor (which uses little-endian, and a 64k memory space) needs to use these tables. Using objcopy with --reverse-bytes on the object file in question before linking might've been a solution, but I also need to do some bitwise logic on the addresses. What I'd actually like to assemble is something like this:

top_label:
.db (label_a%256), ((label_a>>8)&0x7f)|0x80
.db (label_b%256), ((label_b>>8)&0x7f)|0x80
.db (label_c%256), ((label_c>>8)&0x7f)|0x80

That won't assemble because GAS complains about an "incorrect section" for those operations, probably because part of the expressions aren't absolute.
Is it at all possible to do label arithmetic such as this with GAS? If not - is there some other good 68k cross-assembler for wintel?

What's your target platform? And what version of GAS are you using?

My target platform is the Sega Megadrive, and I'm using binutils 2.18 (m68k-elf).

uhh, isn´t there another choice maybe ?

i mean: this ain´t straight-forward :p !

Okay, I'll admit that I don't know much about dev tools on the Megadrive. Vasm (http://sun.hasenbraten.de/vasm/index.php?view=main) is a neat 68000 (cross-)assembler, unfortunately I don't see support explicitly for the Megadrive. Since the author is usually open to adding new target platforms, it wouldn't hurt to mail him asking for that.

Anyway, what I can suggest at the moment regarding your question(s) is:

- Since you're linking to a ROM file I suppose you're using absolute addresses. Most 68k assemblers (no idea about GAS) can assemble at absolute addresses using the ORG instruction. Maybe if you include something like this at the top of your code, GAS will get the point and stop complaining?
- Another idea would be to do this at runtime, something like:


(I'm not sure about the bset/bclr, that's what I think you're doing - I'm typing this fastish as I have to attend to something else soon :))

So this will generate the address regardless of the assembler. Hope this helps.

Hi mic,

i think the GAS complains about the "%" operator, which is multiply used in GAS as far as i can remember. Have you tried using "&255" instead of "%256", which will result in the same byte value ?

Good luck with it ...

@ggn: That's what I'm doing now, because now I'm copying the tables to the co-processor's (Z80) RAM. But I want to have the tables in ROM instead, to avoid wasting precious Z80 RAM. In case you're wondering why I don't just generate data for a Z80 assembler instead, it's because I don't want to assemble the data at some hardcoded address.
I don't use ORG at all. I use a .text section and a .bss section, and then I supply a linker script for LD which contains the base addresses for each section.

@Paranoid: Nope, still same error.


As a last resort I guess I could change the Z80 code that accesses these tables so that instead of:

ld hl,(table)

I'll do something like:

ld a,(table)
or $80
ld h,a
ld a,(table+1)
ld l,a

Though I would rather have avoided that.

Never used GAS nor any megadrive, but I would expect something like this:

top_label:
.dw ( ((label_a&256)<<8) | (((label_a>>8)&0x7f)|0x80) )
.dw ( ((label_b&256)<<8) | (((label_b>>8)&0x7f)|0x80) )
.dw ( ((label_c&256)<<8) | (((label_c>>8)&0x7f)|0x80) )

hence the parenthesis are just to force evaluation, I've seen puking horses ;)

ofcourse one can try % (no <<8) but always use maximum parenthesis *G*

FAIL! :D

Yeah, yeah, you whiny biatch, I know this won't assemble! Like I said, I wrote it in a hurry :)

@Danzig
You mean "&255", surely..

That it won't assemble is not the only FAIL. :D

Whine whine whine :P

@xeron: SURE, thanks for nit-pick ;) copy/paste