Hardcode bitplane pointers in copperlist?

[a/b]

Yeah, that might "work" in proasm, but it's wrong (bug?): reloc-abs should result in a reloc. It's not different than reloc +/- offset.

[Bruce Abbott]

Originally Posted by a/b

Yeah, that might "work" in proasm, but it's wrong (bug?): reloc-abs should result in a reloc. It's not different than reloc +/- offset.

address - address = number. Every assembler should be happy with it.

Of course this only works with absolute code (no relocs involved). The reason it doesn't work with load modules is that the loader only relocates 32 bit numbers, and the copper list has 16 bit numbers.

BTW the only reason I developed this macro was for use with my disassembler, where it is required to generate assemblable source code. In my own code I generate the numbers at run time, which works everywhere.

[a/b]

Originally Posted by Bruce Abbott

address - address = number. Every assembler should be happy with it.

Generally speaking, assemblers don't use just plain addresses/numbers, they use symbols instead. Number is just a part of that, the other typical parts are section and type/attributes (abs, reloc, var, const, register/EQUR, ...) and they determine what operations can be performed.
So when you send a string down to the expression parser/evaluator you don't get back just a number. On the surface it might look simple but there's a lot going on in the background. And then, if the asm is multi-pass, you often get "undefined" values and have to defer to pass2+.
reloc1-reloc2 works fine with relocs, and in some asms they don't have to be in the same section, while the others won't accept the shorthand version and you have to write it as e.g. (reloc1-start1)-(reloc2-start2), with extra subtractions as explicite conversion from reloc to abs const, which can be then used with fewer constraints.
All this text because OP is dealing with relocs, and if everything is abs then yeah, hack away just as back in the old ORG/LOAD days ;p.

[phx]

Originally Posted by a/b

reloc-abs should result in a reloc.

I tend to agree (if "abs" means absolute address label). It would be logical. Although I cannot imagine a use-case for adding or subtracting a label from an ORG-section.

I was confused, because vasm, like ProAsm, flagged the resulting expression as constant. This happens because an

org

within a relocatable code section is treated as a block of absolutely relocated code within that relocatable section. So, technically it's still the same section and distances between labels from the same section are constant.

I should proably fix that.

Originally Posted by Bruce Abbott

address - address = number. Every assembler should be happy with it.

An address is also a "number". The important difference is if an expression can be evaluated as being constant at compile time or not.

Of course this only works with absolute code (no relocs involved).

I wonder why you need that macro trick with labels from absolute code? There should be no problem.

[Bruce Abbott]

Originally Posted by a/b

Generally speaking, assemblers don't use just plain addresses/numbers, they use symbols instead. Number is just a part of that, the other typical parts are section and type/attributes (abs, reloc, var, const, register/EQUR, ...) and they determine what operations can be performed.

Yes, and the assembler will deal with those types according to what they are used for.

A label represents an offset from the start of the section, whose value isn't known until the code has been parsed. In a load module the OS relocates it to an absolute value by adding the address of the start of the section it is relative to in memory. When generating absolute code the assembler 'relocates' the value itself, by adding the ORG address to it when creating the output file.

When one label is subtracted from another the result is an absolute value that is also not defined until pass 2, but does not require relocating. Therefore the assembler treats it differently. Constant values created with 'equ' or '=' are a third type that is defined in pass 1. The question is what happens when you mix them, eg. adding an absolute value to a label.

Page 83 of the Devpac 3 manual has a chart showing allowable type combinations and results. An 'A' (absolute) value added to or subtracted from an 'R' (relative) value results in an 'R'. 'R' - 'R' = 'A', but 'R' + 'R' is illegal. Logical operations are not permitted on 'R' values. However (not mentioned in the manual) this rule is relaxed when generating absolute code, presumably because the assembler has already converted the 'R's to 'A's by the time it does the calculation.

reloc1-reloc2 works fine with relocs, and in some asms they don't have to be in the same section, while the others won't accept the shorthand version and you have to write it as e.g. (reloc1-start1)-(reloc2-start2), with extra subtractions as explicite conversion from reloc to abs const, which can be then used with fewer constraints.
All this text because OP is dealing with relocs, and if everything is abs then yeah, hack away just as back in the old ORG/LOAD days ;p.

Both ProAsm and Basm (Barfly assembler) require the method I used to convert the 'R' value to an 'A' value before applying logical operations to it. It could be argued that they are being too picky here when generating absolute code, but that's how they work.

Why not just use another assembler, you say? The reason is that they are the fastest by far. I paid to get ProAsm registered back in 1996 and have used it ever since, so I prefer it over Basm even though it assembles at only half the speed (but 5-10 times faster than Devpac). The other problem with Devpac is that it doesn't output binary files, only S-records or (absolute) linker files.

All this text because OP is dealing with relocs, and if everything is abs then yeah, hack away just as back in the old ORG/LOAD days ;p.

Yeah, the OP appears to be using an AsmOne style assembler so a lot of this discussion may not be relevant to their situation, but it's still worth discussing IMO.

[Bruce Abbott]

Originally Posted by phx

Did you really test it?

I have only tested it on reassembling a disassembled binary file. If there is something wrong with it with please tell me.

I used this macro to assist with reassembling source code produced by my disassembler. It is only included in the disassembly of binary files or memory, not load modules. This code will never appear in a load module unless it has absolute code embedded in it (which my disassembler doesn't recognize, so...).

I recently changed my disassembler to use two CMOVE's rather than this macro, which makes it more 'transparent' (ie. you can see what it's doing). Now I have to test other assemblers to see what they need - no rest for the wicked!

You found a way to trick the assembler, so you no longer get the helpful error message. But in the end you trick yourself, because the relocation information is missing and the bitplane addresses are wrong after starting the program.

There is no relocation information in a binary file.

The address will be correct relative to the specified ORG address. It is the programmer's responsibility to ensure that the code and data gets there (ie. by loading or moving it to the correct address). For this and other reasons I recommend calculating the values at run time, if practicable.

[Photon]

Bruce - OP wants the impossible: to declare a (too) modified value from a label, and have it relocatable in a section.

As correctly stated, no code, assembler (or compiler) can fix this (until the Amiga exe hunk format supports it - currently, it supports longword only pointer +/- absolute offset).

This to say that ORG or runtime solutions are not part of the question, which wants to (impossibly) avoid those.

[KONEY]

I reached a compromise,

first I put the label I want in the copperlist, like this:

PHP Code:

Copper:
    ...
    .BplPtrs:
    DC.W $E0
    DC.W $E2
    DC.L BG1
    DC.W $E4,... 


Then before starting it I fix it but without needing to provide any label:

PHP Code:

    LEA    Copper\.BplPtrs+2,a1
    MOVE.L    (A1),D0
    SWAP    D0
    MOVE.L    D0,(A1) 


No guru so far so I may well say it works

[Photon]

...which is like PokePtrs, but with disadvantages (hard to read copperlist which will be invalid if the swapping code isn't run (in time)) and none of the advantages (dynamic, PC- or register-relativity possible).

IDK about that one.

Maybe as code obfuscation as part of copy protection, except... the error is clear and to do with the Copper, so it will be found quickly.