Good Afternoon.

After a long break, I decided to start work/play on the Sinclair QL FPC cross compiler.

I noticed that using any release of the vasm assembler, from 1.9 onwards, breaks the "crossall" build. It spits out a number of "warning 1007: scratch at the end of line" errors, then the build fails with 2 errors -- neither of which are displayed.

Reverting back to any of the 1.8 releases, 1.8l (ell) is the latest, and the build works fine.

I'm pretty sure almost nobody is building the cross compiler for this particular bit of 1980s hardware, other than myself and a couple of others, but hopefully this message will be useful to someone. It could be that the later versions of the assembler are going to break other M68K systems?

For best results, the 1.8l version of vasm can be obtained from http://phoenix.owl.de/tags/vasm1_8l.tar.gz and this is the most recent version of the assembler that will help build the cross compiler.

Cheers,
Norm.

Hi,

I think that my daily tests are using vasm 1.9 for sinclairql, and I have no problems with them.

could you please be a little more specific about the exact version of the compiler and the make command line you are using?

I used current trunk compiler with:
make crossall CPU_TARGET=m68k OS_TARGET=sinclairql OPT="-n -vx"

which uses version 1.9c
/home/muller/bin/m68k-sinclairql-vasmm68k_std
vasm 1.9 (c) in 2002-2022 Volker Barthelmann

And completes successfully:
make[2]: Leaving directory '/home/muller/pas/gitlab-fpc-source' /usr/bin/echo Build > build-stamp.m68k-sinclairql
/usr/bin/echo Build > base.build-stamp.m68k-sinclairql make[1]: Leaving directory '/home/muller/pas/gitlab-fpc-source'

Pierre

Le 18/04/2023 à 16:14, Norman Dunbar via fpc-pascal a écrit :

Hi Pierre,

could you please be a little more specific about the exact version of the compiler and the make command line you are using?

I'm, on 64 bit Linux Mint 21.1 (Vera) all patches applied.

I'm using the latest Linux x86-64 version of FPC. I have the latest source code from gitlab, which appears to be 3.3.1, I run the following commands to perform a build:

cd ~/SourceCode/fpc

make clean OS_TARGET=sinclairql CPU_TARGET=m68k

make crossall OS_TARGET=sinclairql CPU_TARGET=m68k

### All on one line!
make crossinstall OS_TARGET=sinclairql CPU_TARGET=m68k INSTALL_PREFIX="/home/norman/bin"

I see that you have some options on your make command, which I've never had to use in the past when building the compiler. Hang on while I retest...

Nope, still fails.

I rebuilt the assembler with release 1.9c and installed it in the usual manner, which has always worked.

When I rebuild the compiler, with a "make clean" followed by a "make crossall" as per your command above, it spits out numerous "warning 1007" messages.

The start of all the problems is this:

make[4]: Entering directory '/data/SourceCode/fpc/rtl/sinclairql'

/usr/bin/mkdir -p /data/SourceCode/fpc/rtl/units/m68k-sinclairql

/data/SourceCode/fpc/compiler/ppcross68k -Ur -Tsinclairql -Pm68k -XPm68k-sinclairql- -Ur -Xs -O2 -n -Fi../inc -Fi../m68k -Fim68k -FE. -FU/data/SourceCode/fpc/rtl/units/m68k-sinclairql -n -vx -dm68k -dRELEASE -Us -Sg @rtl.cfg system.pp

Executing "/usr/local/bin/m68k-sinclairql-vasmm68k_std" with command line "-quiet -elfregs -gas -Felf -m68000 -o
/data/SourceCode/fpc/rtl/units/m68k-sinclairql/system.o /data/SourceCode/fpc/rtl/units/m68k-sinclairql/system.s"

warning 1007 in line 4 of
"/data/SourceCode/fpc/rtl/units/m68k-sinclairql/system.s": scratch at end of line

.section .text.n_system_$$_mt_frjob$longint$longint,"awx"

... this repeats for aome time up until:

warning 1007 in line 73309 of
"/data/SourceCode/fpc/rtl/units/m68k-sinclairql/system.s": scratch at end of line

.section .data.n_RTTI_$SYSTEM_$$_QLCONHANDLE,"aw"

system.pp(438) Error: Error while assembling exitcode 1 system.pp(438) Fatal: There were 2 errors compiling module, stopping Fatal: Compilation aborted

This doesn't happen with the 1.8 releases of vasm. There are no "warning 1007" messages with that one and everything compiles happily.

With the 1.8x releases, I get this instead:

make[4]: Entering directory '/data/SourceCode/fpc/rtl/sinclairql'

/usr/bin/mkdir -p /data/SourceCode/fpc/rtl/units/m68k-sinclairql

/data/SourceCode/fpc/compiler/ppcross68k -Ur -Tsinclairql -Pm68k -XPm68k-sinclairql- -Ur -Xs -O2 -n -Fi../inc -Fi../m68k -Fim68k -FE. -FU/data/SourceCode/fpc/rtl/units/m68k-sinclairql -n -vx -dm68k -dRELEASE -Us -Sg @rtl.cfg system.pp

Executing "/usr/local/bin/m68k-sinclairql-vasmm68k_std" with command line "-quiet -elfregs -gas -Felf -m68000 -o
/data/SourceCode/fpc/rtl/units/m68k-sinclairql/system.o /data/SourceCode/fpc/rtl/units/m68k-sinclairql/system.s"

It then proceeds to compile the remaining "pp" files.

If it helps, I built the vasm assembler as follows:

wget http://sun.hasenbraten.de/vasm/release/vasm.tar.gz

tar -xzf vasm.tar.gz

cd vasm

make clean CPU=m68k SYNTAX=std

make CPU=m68k SYNTAX=std

sudo cp vasmm68k_std /usr/local/bin/

cd /usr/local/bin

sudo ln -s vasmm68k_std m68k-sinclairql-vasmm68k_std

Cheers,
Norm.

I tried to update to the latest version 1.9c,
and that one indeed does lead to this error:
Executing "/home/muller/bin/m68k-sinclairql-vasmm68k_std" with command line "-quiet -elfregs -gas -Felf -m68000 -o /home/muller/pas/gitlab-fpc-source/rtl/units/m68k-sinclairql/system.o /home/muller/pas/gitlab-fpc-source/rtl/units/m68k-sinclairql/system.s"

warning 1007 in line 4 of "/home/muller/pas/gitlab-fpc-source/rtl/units/m68k-sinclairql/system.s": scratch at end of line

.section .text.n_system_$$_mt_frjob$longint$longint,"awx"

So the regression appeared between versions 1.9 and 1.9c. Checking of versions 1_9a and 1_9b confirms that the problem appeared in version 1_9a.

Pierre

Le 18/04/2023 à 16:43, Pierre Muller via fpc-pascal a écrit :

Pierre Muller wrote

...> Checking of versions 1_9a and 1_9b confirms that the problem appeared in version 1_9a.

I can confirm this. Release 1.9 is indeed working fine, everything more recent is failing.

I'm wondering where we go from here? The VASM home page doesn't seem to have any bug reporting facilities. Is there something that the FPC project can take forward, or should I attempt to find a link etc to report bugs in vasm?

Thanks for your help in this.

Cheers,
Norm.

Hi,

Norman Dunbar wrote

I'm wondering where we go from here? The VASM home page doesn't seem to have any bug reporting facilities. Is there something that the FPC project can take forward, or should I attempt to find a link etc to report bugs in vasm?

I recently also became aware of this issue, as I was setting up my new build environment on my new laptop. Thanks to this, I was already aware of this, but I had no time to talk to Frank Wille, the maintainer of VASM yet, due to other things I was busy with. I have to talk to him anyway regarding other issues too. For now, it's great that you and Pierre confirmed the issue.

Please stick to vasm 1.9 until further notice on m68k, and I'll get this sorted.

Charlie

Thanks Charlie, I will be staying on 1.9 until further notice.

Cheers,
Norm.

Hi,

Norman Dunbar wrote

Thanks Charlie, I will be staying on 1.9 until further notice.

I was in touch with Frank Wille, and he confirmed the issue was indeed in vasm, and he provided a fix. You can try to download the "Daily Snapshot", from the vasm site, and try it:

http://sun.hasenbraten.de/vasm/index.php?view=source

Note that this is just what it says on the tin - a daily source sanpshot, and he'll release 1.9d officially later. Can you confirm that this fixes your issue?

Charlie

I'm away from my QL until next week, but I'll check it then. I'll post a note on the QL Forum and see if some other affected users can test quicker.

Many thanks.

Cheers,
Norm.

I tested it for m68k-sinclairql trunk target,
and the rtl and packages completed successfully with this daily snapshot.

Great!

Pierre

Le 21/04/2023 à 14:19, Karoly Balogh via fpc-pascal a écrit :

Much obliged, thank you.

Cheers,
Norm.

Hi,

I downloaded the updated version of vasm v1.9d and compiled and installed as per Norman's document.

The cross compiler compiled with no errors and I was able to compile a 'Hello World' program and execute the compiled program in a QL Emulator.

Regards,
Derek

I have posted details on the QLb Forum and I've had a response that it all works fine now.

Please convey our thanks to Frank.

Cheers,
Norm.

Hi,

Derek wrote

I downloaded the updated version of vasm v1.9d and compiled and installed as per Norman's document.

Just as a final update to this thread, Frank informed me, that the official vasm 1.9d release is now out, so all users should upgrade to that instead of using the daily snapshot. Just in case.

Charlie

I tested 1.9d version on a test machine,
m68k targets are OK, but z80 targets now fail with:

Executing "/FPC/compilers/cross-compiling/bin/z80-msxdos-vasmz80_std" with command line "-quiet -Fvobj -o /FPC/compilers/cross-compiling/pas/trunk/fpcsrc/rtl/units/z80-msxdos/si_prc.o /FPC/compilers/cross-compiling/pas/trunk/fpcsrc/rtl/units/z80-msxdos/si error 39 in line 95 of "/FPC/compilers/cross-compiling/pas/trunk/fpcsrc/rtl/units/z80-msxdos/si_prc.s": illegal relocation

.word .Lc2,.Lc1-.Lc2

_prc.s"
si_prc.pp(67,4) Error: Error while assembling exitcode 1
si_prc.pp(67,4) Fatal: There were 2 errors compiling module, stopping
Fatal: Compilation aborted

Pierre

Le 24/04/2023 à 15:27, Karoly Balogh via fpc-pascal a écrit :

Hi,

I'm not sure it was Nikolay's intention to support vasm for Z80, it was a hack from be before the internal assembler existed... -.-'

Anyway, can you figure out when did it break? Did it work with 1.9c? Which was the previous version you used?

Charlie

Le 25/04/2023 à 10:40, Karoly Balogh a écrit :

I finally managed to take a look at this issue:
it seems to be related to some 'bug' inside our code: rtl/zxspectrum/si_prc.pp contains this:

{ this *must* always remain the first procedure with code in this unit } procedure _start; assembler; nostackframe; public name 'start'; label

   bstart,bend,loop,loop2,our_int_handler,key_int;

asm
{ init the stack }
ld sp, offset fpc_stackarea_end

.... (Some z80 assembly code removed *)
{ When using the SDCC-SDLDZ80 linker, the first object module defines the order of areas (sections). Since this module contains the startup code, it is loaded first, so we define all the sections we use in the proper order. }
area '_DATA'
area '_BSS'
bstart:
area '_BSSEND'
bend:
area '_HEAP'
area '_STACK'
area '_CODE'
end;

end.

The problem is that the assembly always generates some .debug_frame section, even if -g- is used, and this section contains:
.word .Lc2,.Lc1-.Lc2
With .Lc2 being the start of _start code, and .Lc1 supposed to be at the end of _start.

But the area pseudo-instructions do generate new .section instructions, which lead vasmz80_std to rightfully consider that .Lc1-.Lc2 is illegal because the two labels do not belong to the same section anymore...

The problem is that I have no idea how to fix this issue... Would it be possible to move the area pseudo-instructions elsewhere?

Pierre

PS:
Copying the .section entry of _start right before .Lc1 (like below) fixes the assembly using vasmz80_std

.section .text.n_si_prc_$$__start,"acrx"
.Lc1:

Pierre