VASM交叉汇编器问题（M68K） [英] VASM cross-assembler issue (m68k)
问题描述
我想知道是否有人可以使用VASM汇编程序为Amiga编译MC68000二进制文件来解决我遇到的烦人问题。问题在于标签地址操作的错误（我认为）实现。
以下是详细信息：
I'm wondering if anyone can help me with an annoying issue I face using VASM assembler to compile MC68000 binaries for Amiga. The problem lies in buggy (I think) implementation of labels' addresses manipulations.
Here are the details:
copper_scr:
dc.w $e0, (screen>>16) & $ffff
dc.w $e2, screen & $ffff
...
screen:
dcb.w screen_size ; screen_size value does not matter here
我在上面的代码中试图做的是分割屏幕地址分为最高有效字和较低有效字，以便为芯片寄存器提供屏幕数据地址（或向量，如果您愿意）。
What I'm trying to do in the code above is to split screen address into most significant word and less significant word in order to feed chip registers with screen data address (or vector if you wish).
但是，这种形式的代码编译给我非法重定位错误39。
However, compilation of code in this shape gives me the "illegal relocation" error 39.
我尝试了多种方法来消除此错误，因为我认为既然屏幕地址很长（即不是单词）， screen >> 16的结果可能会保留很长时间，因此我不能将这个值放在整个单词范围内。
I tried many ways to get rid of this, as I supposed that since screen address is long (i.e. not word) the result of "screen>>16" might remain long and therefore I cannot put such a value into word-wide place.
有趣的是，以下代码编译没有错误，但结果二进制文件中的两个值都被编译为0：
What's interesting, the following code compiles with no errors, but both values in resulting binary are compiled to a value of 0:
...
dc.w $e0,0 + screen>>16 & $ffff
dc.w $e2,0 + screen&$ffff
...
作为暂时的变通办法，我在运行时在代码开头的某个位置计算这些值：
As a temporal dirty workaround I calculate those values at runtime somewhere at the beginning of code:
move.l #screen,a0
move.l a0,d7
lsr.l #4,d7
lsr.l #4,d7
lsr.l #4,d7
lsr.l #4,d7
andi.l #$ffff,d7
move.w d7,copper_scr+2
move.l a0,d7
andi.l #$ffff,d7
move.w d7,copper_scr+6
但这显然是荒谬的，完全错误。
but that is obviously ridiculous and totally wrong.
任何帮助表示赞赏。
推荐答案
问题在于汇编器（和链接器）工作：
The problem lies in the way the assembler (and linker) works:
一些汇编器已经知道以后将在某些地址放置一些代码，而其他汇编器则写目标文件，并且链接器将决定数据的位置
Some assemblers already know at which address some code will later be placed while other assemblers write object files and the linker will decide where the data will be placed.
在目标文件中，诸如 dc.w 1234 + screen>>>& 16的指令。 $ ffff 将存储为 dc.w 1234 ，并存储其他信息，即 screen <一旦知道屏幕的地址，就必须将/ code>添加到 1234 。
In the object file an instruction like dc.w 1234 + screen>>16 & $ffff will be stored as dc.w 1234 and an additional information is stored that the high 16 bits of screen must be added to 1234 as soon as the address of screen is known.
不幸的是，存在两个问题：
Unfortunately there are two problems:
-
并非所有架构都支持所有类型的信息。例如，Sparc CPU的目标文件支持信息 将地址的低10位添加到值（因为此类CPU的指令使用地址的低10位），而目标文件则为m68k不支持 地址的低10位信息类型。
Not all architectures support all types of information. Object files for Sparc CPUs for example support an information "add the low 10 bits of an address to a value" (because such CPUs have instructions using the low 10 bits of an address) while object files for m68k do not support the "low 10 bits of an address" information type.
不幸的是， 地址的高16位信息类型也不受m68k目标文件支持。 （至少不使用GNU工具-我不确定VASM。）
Unfortunately the "high 16 bits of an address" information type is also not supported by m68k object files. (At least not if you use the GNU tools - I'm not sure about VASM.)
汇编器很愚蠢。他们不会检测到 screen>>< 16& $ ffff 等于 地址的高16位。因此，即使您的文件格式（例如PowerPC目标文件）支持该类型的信息，汇编程序也会有问题。
Assemblers are stupid. They will not detect that screen>>16 & $ffff is equal to "the high 16 bits of an address". So even if your file format (PowerPC object files, for example) supports that type of information the assembler will have a problem.
可能的解决方法：
如果您在相同部分中有标签，并且您肯定知道该标签的地址，则可以请执行以下操作。
If you have a label in the same section and you definitely know the address of that label you can do the following.
我们假设您知道标签 xyz 将被加载到地址
Let's assume you know that the label xyz will be loaded into address $1234 in the memory later.
现在您可以执行以下操作：
Now you can do the following:
xyz:
...
dc.w $e0, 0 + (screen - xyz + $1234) >> 16 & $ffff
...
screen:
但是，如果您不这样做知道任何标签的最终地址都会有问题...
However if you don't know the "final" address of any label you'll have a problem...
这篇关于VASM交叉汇编器问题（M68K）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
