Operand must be relocatable

[16bitPM]

Hi all,

I'm trying to convert the famous 256b demo "LATTICE" (Full source code here) from FASM to MASM syntax.
I'm stuck at the following:



PALETTE: mov dx,3c8h
ZMOVE    EQU $-2

...
...

DRAWX:   mov si,EYE
EYE      EQU $-2

...
...

ROTATE: fild word ptr [si-EYE+ZMOVE]   <<----


Lines like the one marked with <<---- fail with error A2094: operand must be relocatable.
I can see why it doesn't work, but somehow it works in FASM and I don't know how to do it properly in MASM.

Thx :-)

[_japheth]

Code Select Expand


PALETTE: mov dx,3c8h
ZMOVE    EQU $-2
...
...
DRAWX:   mov si,EYE
EYE      EQU $-2
...
...
ROTATE: fild word ptr [si-EYE+ZMOVE]   <<----

I can see why it doesn't work, but somehow it works in FASM and I don't know how to do it properly in MASM.

Both EYE and ZMOVE contain the $ symbol, making them "relocatable labels". You cannot add relocatable labels. but you can subtract them - if they are in the very same segment. So perhaps change the line to:

Code Select Expand

ROTATE: fild word ptr [si+(ZMOVE-EYE)]

Btw., Fasm doesn't know "offset" - I guess that line

Code Select Expand

DRAWX:   mov si,EYE

must be

Code Select Expand

DRAWX:   mov si,offset EYE

in Masm syntax.

[16bitPM]

Thanks!! I'll try that out.

Btw., Fasm doesn't know "offset" - I guess that line

Code Select Expand

DRAWX:   mov si,EYE

must be

Code Select Expand

DRAWX:   mov si,offset EYE

in Masm syntax.

Well, EYE is an EQU,so I expect that OFFSET won't work.

Diederik.
PS: I still use your JWASM for retro fun. I find UASM too overbloated and your assembler is a gem and works great!

[_japheth]

Well, EYE is an EQU,so I expect that OFFSET won't work.

Masm's EQU is a very strange beast. It can be used to define constants, text equates or (relocatable) labels; for labels, OFFSET should ( and will ) work.

PS: I still use your JWASM for retro fun. I find UASM too overbloated and your assembler is a gem and works great!

Thanks, good to know! It's still updated on occation, but I'm no big fan of that SIMD stuff, hence a bit too lazy to add the newest 512-/1024-/2048-/...bit instructions.

[16bitPM]

Thank you, kind Sir! Your first suggestion worked!

The EQU wasn't needed, but the application crashes on exit. Oh well, I'll figure it out.

Thanks, good to know! It's still updated on occation, but I'm no big fan of that SIMD stuff, hence a bit too lazy to add the newest 512-/1024-/2048-/...bit instructions.

Not to mention the convoluted HLA stuff. I mean up to a certain point sure, but if it gets too big I'd switch to a higher level language and if needed do inline asm there.

Anyway programming modern processors is not fun anymore. Setting up a system has become very complex and tedious, and it's very hard to outperform a modern compiler. Modern assembly also isn't exactly elegant, if you care about performance. And I use assembly on old computers anyway (286, 386, Pentium, ...).

I've had some secret wishes though, but I don't think anyone else on the planet really cares, so...
(it's about support for true LIDATA structures, some of the not-implemented MASM features for full compatibility, Turbo Debugger compatibility and a way to exploit more of the obscure x86 stuff, such as separately define segment granularity, mainly for low-level stuff).

I tried to do the LIDATA-fix myself by looking at the MASM 5 and JWASM source code, but I just don't know enough about assemblers, compilers and linkers, NOR how to do open-source contributions properly... and it seemed much more difficult to do than I anticipated.

Also JWASMR.EXE sometimes crashes the computer with certain errors. If I can reproduce it I'll make a bug fix (I wasn't aware that JWASM was still maintained somehow). JWASMR is relevant for me because it gives me MASM 6 syntax on 16-bit CPU's. But let's be honest: this is a hobby.

Have a nice day :-)

[TimoVJL]

perhaps a conditionally compiled jwasm for 16-bit only could be useful ?

[16bitPM]

I found that both MASM and JWASM produce different opcodes in several places. Mostly it doesn't matter (like 8-bit adc instructions) but there is one place where it may:

dec word ptr [bp-160+ZMOVE]

gets a 16-bit displacement instead of 8-bit with encoding FF 8E 71 00, which makes the code length 1 byte longer. I have no idea how to force this to 8-bit. Switching ZMOVE and 160 doesn't make a difference. Replacing the displacement with LOW(ZMOVE-160) changes the encoding to FF 8E 71 01.
The code generated by FASM is FF 4E 71.

The original code in FASM is

dec word [byte bp-160+ZMOVE]


~D~

[16bitPM]

perhaps a conditionally compiled jwasm for 16-bit only could be useful ?

That's what JWASMR is.

[_japheth]

I found that both MASM and JWASM produce different opcodes in several places. Mostly it doesn't matter (like 8-bit adc instructions) but there is one place where it may:

dec word ptr [bp-160+ZMOVE]

gets a 16-bit displacement instead of 8-bit with encoding FF 8E 71 00, which makes the code length 1 byte longer. I have no idea how to force this to 8-bit.

Are you sure that Masm generates a 1-byte offset? IIRC, if a relocatable label is involved, both Masm and JWasm will always generate a 16-bit displacement ( since the actual value is calculated at link time only ).

However, you can overcome this if there's just 1 source. For this you'll have to change the label to a constant; this can be done by subtracting 2 labels, the second one pointing to the very first byte of the code:

Code Select Expand

         .code
startlabel:

PALETTE: mov dx,3c8h
ZMOVE    EQU $-2
ZMOVEX   EQU ($-2-startlabel) AND 0ffffffffh ; the "AND xxx" required by JWasm only, probably a bug...
...
         dec word ptr [bp-160+ZMOVEX]


[daydreamer]

Anyway programming modern processors is not fun anymore. Setting up a system has become very complex and tedious, and it's very hard to outperform a modern compiler. Modern assembly also isn't exactly elegant, if you care about performance. And I use assembly on old computers anyway (286, 386, Pentium, ...).

I have tried write some tiny Dos16bit demos/games,the challenge of slow few mhz cpu and lack of gigabytes of memory makes it a real challenge compared to 32bit/64bit several ghz cpu and very fast hardware accelerated gpus
unfinished projects,but still fun,ok I run on DOSbox
there are still many algos/code that worked well on 16bit regs or smaller registers

[16bitPM]

Are you sure that Masm generates a 1-byte offset? IIRC, if a relocatable label is involved, both Masm and JWasm will always generate a 16-bit displacement ( since the actual value is calculated at link time only ).

No I meant, MASM and JWasm produce a different opcode from FASM. Sorry :-)

However, you can overcome this if there's just 1 source. For this you'll have to change the label to a constant; this can be done by subtracting 2 labels, the second one pointing to the very first byte of the code:

Code Select Expand

         .code
startlabel:

PALETTE: mov dx,3c8h
ZMOVE    EQU $-2
ZMOVEX   EQU ($-2-startlabel) AND 0ffffffffh ; the "AND xxx" required by JWasm only, probably a bug...
...
         dec word ptr [bp-160+ZMOVEX]


Naah, that didn't work. I thought you meant AND 0ffh, but that didn't work either (neither JWasm nor MASM 6.11).

[_japheth]

Naah, that didn't work. I thought you meant AND 0ffh, but that didn't work either (neither JWasm nor MASM 6.11).

Ok, I don't know what you tried, but I did some more investigation  - because, as it turned out, there's a (minor) bug in JWasm and a bug in Masm. Here's my (full) test case:

Code Select Expand

;--- subtraction of 2 labels.
;--- jwasm < v2.19 was confused if an intermediate result was negative
;--- due to - erroneously - using 32-bit arithmethic.
;--- since jwasm v2.19, all calculation is 64-bit.

;--- Masm also has a bug - it does truncate the displacement

.286
.model tiny
.stack

.code
@:
mov si, offset Z2
;Z2  equ ($ - 2 - @) and 0ffffh   ; workaround - works with JWasm < v2.19
Z2  equ ($ - 2 - @)       ; this works since JWasm v2.19

start:
inc word ptr [bp-129+Z2]  ; ok, byte displ with Masm/JWasm
inc word ptr [bp-130+Z2]  ; JWasm ok; Masm truncates to a byte displ - bug!?
inc word ptr [bp-130+1]   ; ok, word displ
mov ah,4ch
int 21h
END start

It's 16-bit code, because your code also was 16-bit, but it's actually also relevant for 32-bit ( most likely also for 64-bit ).

[16bitPM]

It's 16-bit code, because your code also was 16-bit, but it's actually also relevant for 32-bit ( most likely also for 64-bit ).

Well, well, well!!
Shall I make a bug fix request on Github?