Fails to build with GNU as from binutils 2.35.1

[swolchok]

cc    -c -o start.o start.S
cc  -g -fno-pie -Os -D__REAL_MODE__ -wrapper ./realify.sh -ffixed-r8 -ffixed-r9 -ffixed-r10 -ffixed-r11 -ffixed-r12 -ffixed-r13 -ffixed-r14 -ffixed-r15 -mno-red-zone -fcall-used-rbx -fno-jump-tables -fno-shrink-wrap -fno-schedule-insns2 -flive-range-shrinkage -fno-omit-frame-pointer -momit-leaf-frame-pointer -mpreferred-stack-boundary=3 -fno-delete-null-pointer-checks -c -o lisp.real.o lisp.c
/tmp/ccy4ZtIH.s: Assembler messages:
/tmp/ccy4ZtIH.s:189: Error: incorrect register `%dx' used with `l' suffix
/tmp/ccy4ZtIH.s:275: Error: incorrect register `%bx' used with `l' suffix
/tmp/ccy4ZtIH.s:355: Error: incorrect register `%bx' used with `l' suffix
/tmp/ccy4ZtIH.s:393: Error: incorrect register `%dx' used with `l' suffix
/tmp/ccy4ZtIH.s:979: Error: incorrect register `%ax' used with `l' suffix
/tmp/ccy4ZtIH.s:1080: Error: incorrect register `%ax' used with `l' suffix
make: *** [Makefile:60: lisp.real.o] Error 1
$ cc --version
cc (Ubuntu 10.2.0-13ubuntu1) 10.2.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ file (which cc)
/usr/bin/cc: symbolic link to /etc/alternatives/cc
$ file /etc/alternatives/cc
/etc/alternatives/cc: symbolic link to /usr/bin/gcc

What compiler & version are you using?

[swolchok]

as --version says 2.35.1. I tried with gcc 7.5.0 (which is the oldest Ubuntu groovy has packages for) and still got the same error, so I thought maybe it was the binutils version. I think maybe https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=be4c5e58bdc839898739e0332aee84abf6e5299a broke this based on the commit message? It appears that this change was not present in binutils 2.34 and thus was added in binutils 2.35 or 2.35.1. Will confirm after trying gas from binutils 2.34.

[swolchok]

Confirmed: gas from binutils 2.34 works.

[jart]

Try just not building the C code, since it was mostly written for the purpose of generating assembly that was really close to the contents of the sectorlisp.S file. Since the C code was used to generate really tiny real mode assembly, the C was written in a completely esoteric way. Contributions are welcome on fixing the C. Here's how you build just the S:

$ make sectorlisp.bin
$ qemu-system-x86_64 -m 1 -nographic -fda sectorlisp.bin
Booting from Hard Disk...
Boot failed: could not read the boot disk

Booting from Floppy...
(EQ (QUOTE A) (QUOTE A))
T

[jart]

Also for the record:

main jart@nightmare:~/code/sectorlisp$ cc --version
cc (Alpine 9.3.0) 9.3.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

main jart@nightmare:~/code/sectorlisp$ as --version
GNU assembler (GNU Binutils) 2.34
Copyright (C) 2020 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `x86_64-alpine-linux-musl'.

If you really want to build the C code then there's prebuilt static toolchain binaries in this folder that are 100% guaranteed to work: https://github.com/jart/cosmopolitan/tree/master/third_party/gcc

[swolchok]

Try just not building the C code

That fixed it, thanks!

Contributions are welcome on fixing the C.

IIUC, I think the problem is realify.sh and/or realify.sed not fixing l instruction suffixes.

qemu

thanks, that would have helped me out earlier this afternoon. I tried blinkenlights, but the column containing the TELETYPEWRITER wasn't showing up for me in either cmd.exe or my WSL2 terminal (which I think is still a conhost terminal?).

By the way, it might be useful to support getting the real mode output of the C compiler and document the process used to go from that output to sectorlisp.S. I screwed up an update in #4 that could have been avoided with a C patch + partial automation of the tuning.

[jart]

I wouldn't want to discourage you from using Blinkenlights! Try making the window bigger. Or making your font size smaller. Blinkenlights is designed to assume the terminal display is modern and huge.

If there isn't enough room then Blinkenlights removes panels as a fallback measure. Ideally it'd have a visual cue for that.

[swolchok]

window bigger

FWIW, this was default font size and full screen on Windows 10 at 1080p resolution.