IRC channel logs

<oriansj>aggi: the z80 was an 8bit processor not 16bit processor. the z280 was the 16bit version of the z80

<oriansj>there are fpga versions of 64bit RISC-V readily available

<oriansj>lanodan: well one wouldn't need coreboot or libreboot to boot a modern operating system. Only a simple BIOS in ROM with a half dozen primitives

<oriansj>which could either be written by hand or cross-compiled on an 8bit system.

<aggi>don't remember exactly how the i286 compared to i8086, which involved MMU, to extend the address space beyond 16bit, too with the z280

<aggi>the z80 did provide 16bit registers and address space

<aggi>in any case, for a long time z80 era systems were more easily coped with to implement free/open hardware, on moderately priced FPGA

<aggi>as a reference, a FPGA capable for ao480 was tagged at ~$800 last time i checked online... that's rather expensive in comparison to what a z80/6502 would need

<aggi>a gigatron ttl shipped for $150

<aggi>i quickly checked the github repo of ao486, and there was some binary-blobs which i couldn't quickly find references to sources and utilities for

<aggi>insofar, 16bit isn't a dead end, it's a necessity still for bootcode/BIOS related parts, and it's the mode which even most high-end x86_64 systems booted with

<aggi>there's another notable difference between i8086 and z80/z280... zilog is in production still, for ~40years

<aggi>the 32bit ao486 is signifcantly more expensive

<aggi>googling for risc-v 64bit FPGA deployments, the Xilinx Nexys4DDR is mentioned, for ~$350, don't know if this includes licenses for development utilities

<aggi>j-core.org documented the fun they had, with Xilinx on a Linux development host... i am not in the mood for this tbh

<aggi>i didn't follow news at the fpga/hardware front for a little while since then, including various free/open development tools for this

<aggi>in any case it seems to have been a huge gap to bridge, to arrive at a 32bit *nix coming from the PDP-11

<oriansj>well I did point out that most 8bit processors had a 16bit address space (that was common)

<aggi>since DEC was proprietary, and defunct since 1998, this could explain how gnu/gcc didn't have a clean system-integration path (wherever it first appeared)

<oriansj>and that 8bit systems could provide a role in the creation of bios and ROMs

<oriansj>also the FSF intentionally avoided 16bit systems as they were likely to be replaced by 32bit systems and it was deemed not worth the effort

<oriansj>and that ultimately was the right choice for creating a POSIX system and ultimately still remains a simple target for bootstrapping

<oriansj>32bit address space, allows one to make a much simpler ISA design (as RISC style designs tend to use 2-4x memory of more complex designs)

<aggi>i merely tried to understand, how GNU/GCC were missing pieces with their bootstrapping (documented in the info docs of gcc-2.7 iirc), and had to rely upon a giant binary seed of unknown origin

<oriansj>aggi: well GNU/GCC skipped the bootstrap from source bit entirely

<oriansj>they went for just ship something which can be built and used

<oriansj>growing outwards to support a bunch of very questionable compilers

<oriansj>but enabled people to quickly get GCC on their system and as vendors started charging for C compilers (Looking at you DEC and Sun) GCC quickly became a default

<oriansj>it wasn't until Guix that giving GCC a proper bootstrap got the effort required to actually do it properly.

<lanodan>Slept on it and primitive coreboot/libreboot reminded me of the stuff Oxide has done on their amd machines, I guess they could try going full firmware bootstrap or close to it even on x86 (quite like how Sun OpenFirmware uses forth for the drivers).

<matrix_bridge><Andrius Štikonas> Well, any FW bootstrap iš machine specific

<matrix_bridge><Andrius Štikonas> Which manęs it much more tedious than kernel bootstrap or userspace bootstrap

<matrix_bridge><Andrius Štikonas> Those are to most extent ISA specific

<matrix_bridge><Andrius Štikonas> Well, kernel bootstrap is FW API specific but there aren't that many of those

<matrix_bridge><cosinusoidally> I managed to run stage0-posix-x86 inside a chroot inside a tmpfs inside the initrd of the slackware 8.1 installer (by bumping ph_memsz in hex2_x86.hex1). That confirms nothing was leaking through when I was running it on a full slackware 8.1 install.

<matrix_bridge><cosinusoidally> My tcc_bootstrap_alt also works

<matrix_bridge><cosinusoidally> Not quite sure which exact version of stage0-posix-x86 I'm using though. Probably an early 2023 one (I was using this copy I incorporated into another one of my projects https://github.com/cosinusoidally/mishmashvm/tree/master/tcc_js_bootstrap/alt_bootstrap/stage0-posix )

<oriansj>lanodan: yeah a FORTH firmware is definitely possible; as is a lisp firmware or basic firmware or anything else someone would like to build. Unfortunately firmware is going to be a constant porting project.

<lanodan>Yeah, just means there's prior art in slapping an interpreter and forth/lisp/… already have small auditable implementations

<oriansj>well the smallest ROM would just be a handful of BIOS calls for disk I/O, basic VGA and keyboard reading. A FORTH would add 4-16KB more upon that and a LISP would add 8-64KB more upon the BIOS requirement.

<oriansj>(Yes I know Boot Sector FORTH and LISP fit in 510 bytes; but you'll want something much better than those)

<oriansj>(as they lack Filesystem support, DISK I/O support or other quality of life essentials)

<aggi>another test-case

<aggi>linux/include/linux/compiler.h:46:2: error: #error "GCC >= 4.2 miscompiles kernel 2.4, do not use it!"

<aggi>GNU/linux got a weird understanding of standard C

IRC channel logs

2024-06-15.log