RMAC and external variable

[+Cyprian]

 

I have a simple code with an external variable:

		.extern         jagbits

and now, that works:

	dc.l	jagbits

 

and that generates an error:

TAKIETAKIE		EQU		jagbits

 

Error message:

rmac -fb -u -v gpu_list.s
gpu_list.s 269: Error: undefined expression
makefile:16: recipe for target 'gpu_list.o' failed
make: *** [gpu_list.o] Error 1

The same error is shown when I use external variable in my macro.

 

is there any workaround?

 

 

[swapd0]

The code IMO has no meaning, you are not defining the value of jagbits, it's an address (defined like a label) or a constant, what it should be?.

 

You must have somewhere something like this

jagbits  equ $1234

or this one

jagbits::   dc.l $1234

 

Edited October 14, 2020 by swapd0

[ggn]

I can suggest 2 things:

 

a) Use .include so both files are assembled in one go. No .extern/.globl required then. And don't worry, rmac's assembly speed is quite fast, you won't notice anything if both files are assembled every time!

b) Use jagbits instead of TALKIETALKIE. rmac's line parser explicitly prohibits EQUing an undefined symbol (and we probably don't want to venture down that avenue as it gets philosophical, or ever religious!)

[+Cyprian]

@swapd0

that variable is defined in makefile

rln $(ALNFLAGS) -o gpuint.cof $(OBJ) -i jaguar.bin jagbits

 

@ggn

 

a) ok, I usually do that - one big .S file, but this time I tried to follow the Atari's workshop way - makefile with separate .S files.

regarding b) when I try to pass jagbits to my macro I see following error message

gpu_list.s 238: Error: undefined expression
gpu_list.s 226: Error: undefined expression
gpu_list.s 226: Error: undefined expression
gpu_list.s 260: Error: undefined expression
gpu_list.s 260: Error: undefined expression
makefile:16: recipe for target 'gpu_list.o' failed

 

if it's needed I can post a source code (it is actually a bit modified Atari's workshop)

 

[ggn]

10 hours ago, Cyprian_K said:

regarding b) when I try to pass jagbits to my macro I see following error message

gpu_list.s 238: Error: undefined expression
gpu_list.s 226: Error: undefined expression
gpu_list.s 226: Error: undefined expression
gpu_list.s 260: Error: undefined expression
gpu_list.s 260: Error: undefined expression
makefile:16: recipe for target 'gpu_list.o' failed

 

if it's needed I can post a source code (it is actually a bit modified Atari's workshop)

 

It might be interesting to post one of the error lines so we could see what the expression is.

[swapd0]

14 hours ago, Cyprian_K said:

@swapd0

that variable is defined in makefile

rln $(ALNFLAGS) -o gpuint.cof $(OBJ) -i jaguar.bin jagbits

 

I don't use rln but, this means that jaguar.bin it's defined as jagbits? you can remove that parameter and do an incbin in your source code, although it looks like the error it's before the linker pass.

Edited October 15, 2020 by swapd0

[+Cyprian]

On 10/15/2020 at 11:55 AM, ggn said:

It might be interesting to post one of the error lines so we could see what the expression is.

Ok, in attached GPUINT.tst.zip in file gpu_list.s I added test macros:

    Macro_Test    UpdateList, 32     ;<--    Works ok
    Macro_Test    jagbits, 32        ;<--    Doesn't work
    Macro_Test    width, 32          ;<--    Doesn't work

 

 

On 10/15/2020 at 3:21 PM, swapd0 said:

I don't use rln but,

how do you generate COF then? rmac with -fb flag gives me only .O file.

On 10/15/2020 at 3:21 PM, swapd0 said:

means that jaguar.bin it's defined as jagbits? you can remove that parameter and do an incbin in your source code, although it looks like the error it's before the linker pass.

yes, in makefile jaguar.bin is defined as jagbits.

ok, now I use ".incbin" for jaguar.bin, and "include" for other .S files, and problem with external variables has gone.

 

but I faced another problem with ".org" in JagTST.zip

currently all variables point to the same address $4000

	lea	v_bmp_lowl,A0
	lea	a_hde,A0
	lea	main_obj_list,A0

When I comment ".org    $4000" from row 62, then those variables point to the same address $0

When additionally I comment ".org    objList" from row 41, they point to correct unique address (based on definition from makefile), but my ".objproc" points to address in the rom. which isn't ok.

 

 

 

 

 

 

GPUINT.tst.zip JagTST.zip

[swapd0]

Put the .org directive at the start of the 68000 code, not at the .bss zone.

		.include        "jaguar.inc"

		.text
		.68000
		.org $4000


Start:

	lea	Start,A0
	lea	v_bmp_lowl,A0
	lea	a_hde,A0
	...

	.bss
	.dphrase

main_obj_list:  .ds.l    16*2
v_bmp_height:     .ds.w    1
v_bmp_highl:      .ds.l    1
v_bmp_lowl:       .ds.l    1


a_hdb:          .ds.w   1
a_hde:          .ds.w   1
a_vdb:          .ds.w   1
a_vde:          .ds.w   1
width:          .ds.w   1
height:	 	.ds.w   1

		.end

 

how do you generate COF then? rmac with -fb flag gives me only .O file.?

 

I'm coding with gcc, it generates a .elf file, although I write some parts in asm.

 

Edited October 28, 2020 by swapd0

[+Cyprian]

  

2 hours ago, swapd0 said:

Put the .org directive at the start of the 68000 code, not at the .bss zone.

it triggers an error message,

JagTST.s 6: Error: .org permitted only in GPU/DSP/OP, 56001, 6502 and 68k (with -fr switch) sections

it seems that's the limitation of RMAC, more than one ".org" isn't allowed in case of Jag 68000 code

 

In that case, I have no problem with that limitation. I'd like to place the only BSS segment in the RAM, and the 68000 code can be placed in the ROM area.

[swapd0]

ops, ok, you don't need to put the org in the 68000 area, I forgot that.

 

35 minutes ago, Cyprian_K said:

  

In that case, I have no problem with that limitation. I'd like to place the only BSS segment in the RAM, and the 68000 code can be placed in the ROM area.

Why? put everything together in RAM. You won't save a lot of memory doing that, all the assets will take a lot more memory, and if you are coding with the real hardware it's a lot faster to upload each version to the RAM than flashing the skunk (if you are using a skunkboard)

[Zerosquare]

In addition, code also runs faster from RAM.

[swapd0]

2 hours ago, Zerosquare said:

In addition, code also runs faster from RAM.

I was thinking about that, RAM is faster than ROM.

[+Cyprian]

11 hours ago, swapd0 said:

ops, ok, you don't need to put the org in the 68000 area, I forgot that.

 

Why? put everything together in RAM. You won't save a lot of memory doing that, all the assets will take a lot more memory, and if you are coding with the real hardware it's a lot faster to upload each version to the RAM than flashing the skunk (if you are using a skunkboard)

I have the skunk but at that moment I use VirtualJag and COF files. It's easier and faster to do some simple tests

 

 

[swapd0]

1 hour ago, Cyprian_K said:

I have the skunk but at that moment I use VirtualJag and COF files. It's easier and faster to do some simple tests

 

 

Until you test on real hardware and doesn't work... I almost never use emulators.

[+Cyprian]

1 hour ago, swapd0 said:

Until you test on real hardware and doesn't work... I almost never use emulators.

understandable, you're more experienced than me and your code is more advanced than mine.

 

I do only some simple tests and VJ is fine for me atm

[+Cyprian]

---deleted---

Edited November 1, 2020 by Cyprian_K

[ggn]

On 10/28/2020 at 7:24 PM, Cyprian_K said:

Ok, in attached GPUINT.tst.zip in file gpu_list.s I added test macros:

    Macro_Test    UpdateList, 32     ;<--    Works ok
    Macro_Test    jagbits, 32        ;<--    Doesn't work
    Macro_Test    width, 32          ;<--    Doesn't work

 

 

how do you generate COF then? rmac with -fb flag gives me only .O file.

yes, in makefile jaguar.bin is defined as jagbits.

ok, now I use ".incbin" for jaguar.bin, and "include" for other .S files, and problem with external variables has gone.

 

but I faced another problem with ".org" in JagTST.zip

currently all variables point to the same address $4000

	lea	v_bmp_lowl,A0
	lea	a_hde,A0
	lea	main_obj_list,A0

When I comment ".org    $4000" from row 62, then those variables point to the same address $0

When additionally I comment ".org    objList" from row 41, they point to correct unique address (based on definition from makefile), but my ".objproc" points to address in the rom. which isn't ok.

 

 

 

 

 

 

GPUINT.tst.zip 17.39 kB · 2 downloads JagTST.zip 18.3 kB · 3 downloads

Right, first of all: sorry for the late reply. I was occupied with random things and kept putting this off.

 

Thanks for the included code, this gives me a good example to explain the limitation here. I'll include the relevant bits below:

        .extern         jagbits
 

        [...]

 

.macro Macro_Test    Macro_Test_DATA, Macro_Test_DATA2
    .Macro_Test_DATA_W1        = \Macro_Test_DATA2 | (\Macro_Test_DATA >> 32)
    .Macro_Test_DATA_W2        = \Macro_Test_DATA2 | (\Macro_Test_DATA & $FFFFFFFF)
    dc.l    .Macro_Test_DATA_W1, .Macro_Test_DATA_W2
.endm
 

        [...]

 

    Macro_Test    jagbits, 32        ;<--    Doesn't work

 

So, let's break this down. First we're asking the assembler to trust us, there is a symbol called "jagbits" defined somewhere else so it's all cool. The assembler replies with "sure buddy, no problem of mine. The linker will have to solve this issue". Then we ask the assembler to do bit manipulation on the symbol and create data based on that. Anyone notice the issue here yet?

 

If the assembler has absolutely no hint what value the symbol contains, how on earth is it supposed to perform maths on it?  And sure, for the sake of argument let's say that we allow this during assembly time and defer this until the fixup pass (where any unresolved symbols had better resolve or else). Since the assembler still has no clue about the symbol, it can't evaluate anything. So that's an error. What would be required here is a way to pass all that stuff to the linker so it can do all the fun operations. As far as I know, that's not a thing for any format and certainly for COFF, unless ELF has some oddball mode that does this (please let this not be the case!).

 

So, how to overcome this? Well, just use externals like they were supposed to, point to actual static addresses! One way to rewrite the above could be:

 

        .extern         jagbits
 

        [...]

 

         move.l #jagbits,d0

         lea our_lovely_addresses,a0

         move.l d0,d1

         lsr.l #32,d0

         move.l d0,(a0)+

         move.l d1,(a1)+

 

Just simply do all the manipulations you want to do during runtime. It'll cost you a very slight fraction of CPU time during init and that's it.

 

Anyway, I hope this sheds some light on the cryptic error messages you stumbled upon.

 

P.S. That macro is very suspicious BTW, why do you assume jagbits to be a 64bit value? While rmac uses 64 bits internally, I really doubt COFF symbols are more than 32 bits. I assume it's probably an example macro, just sayin'!

[+Cyprian]

@ggn yep, that macro was an example, for e.g. extract many sprites from one image.

It's easier to have all needed data in "dc.l" than do a lot of manipulations with 68k code.

Thanks for explanation. Now I can work around that with 'incbin'.

 

What about .org statement?

And I've faced another issue with labels between a .gpu and .68000 code, but I have verify that once more.

Edited November 8, 2020 by Cyprian_K

[ggn]

1 hour ago, Cyprian_K said:

What about .org statement?

Sure, let's talk .org. (spoiler contains some boring history, skip if not interested)

 

Spoiler

Back in ye olde days of MadMac, the assembler was made so it supported two formats: TOS prg and object files. Both of these formats are relocatable and don't allow placing code in absolute positions. If such a think was needed, it was a job for the linker.

 

Then 6502 support was hacked in, where .org was introduced. But only for the 6502 mode.

 

(I'll omit the modifications done to MadMac by Brainstorm as we don't have access to those)

 

Then the source was released to the public by Mr Dyer. SubQMod picked up the source and added Jaguar support. He followed the Brainstorm model of primarily outputting 68k object code with Tom/Jerry code inlined. The 68k code was still handed over to the linker for generating the appropriate output format (coff/abs/plain binary assembled at fixed address, etc).

 

Then that source was picked up by Shamus (and later myself) and DSP56001 mode was added, which allows for multiple .org statements. We still didn't touch the 68k output, .org was still illegal.

 

During another projecta (also this) I decided it would be good to have absolute assembly directly from rmac itself. Thus the -fr switch was introduced, which requires .org.

 

So, the only use case that .org in 68k makes sense is only if you wish to output an absolute addressed binary directly from rmac. This means you can't link object files, everything must be a single compilation unit (i.e. .include all files from one), and only one base address is allowed.

 

Now, it's quite weird that your source (with multiple .org statements) assembles at all without complaining about multiple .org statements. I'll check it again, this might be a bug that should be fixed. In general, don't worry about .org statements in your code. You pass text/data/bss addresses during link time, and that should be all you need. Those segments are assumed by the linker to be contiguous and not have gaps in them. if you do have a special need for multiple starting addresses for your code, then we can talk.

Edited November 8, 2020 by ggn