IRC channel logs

<oriansj>aggi: all software has a bootstrap. Gigatron's path involves python3, JavaScript and c++

<aggi>that's often the case: a few KiB of assembly code couldn't be deployed with simple tools and minimal dependencies

<aggi>while ago, General Electric reported they were planning to keep PDP-11 control system in operation inside their nuclear plants until year2050

<aggi>i suspect the pdp-11 code (the news article explicitely mentined the code only), is run inside emulators nowadays

<aggi>and btw; the gigatron's peripheral i/o (ps/2, vga-out) are proprietary hardware too

<aggi>last time i was searching, i couldn't find a fully free/open vt100 hardware+firmware neither

<aggi>the x.25 stuff that connects power plants and railway grid is in use stil (moved atop virtualized tcp/ip networking), and telekom abandoned support, no vendors remaining

<aggi>i've given up on this, trying to explain

<fossy>stikonas: true

<fossy>maybe we should create a set of shellcheck exclusions for bash 2

<fossy>even for helpers.sh

<stikonas>perhaps

<stikonas>if that work, I'm not against linting all those shell scripts

<fossy>stikonas, Googulator: sorry about PR spam, I just want CI to run each of them through. only #504 and #506 are non-trivial

<fossy>the rest are just removing a file or two

<stikonas>no problem, I'll take a look but might be over the weekend

<stikonas>getting late... (here it is still Friday)

<stikonas>hmm, hopefully oyacc still works on riscv64 :)

<fossy>no worries

<fossy>hmmm, i hope so too....

<stikonas>if not should be fixable

<stikonas>it's a simple application compared to some other stuff we are building

<fossy>How far does riscv get in live-bootstrap at the moment?

<stikonas>up to tcc

<stikonas>then it builds x86 version of tcc 0.9.27 I think

<stikonas>and crashes since that is not riscv64 binary

<fossy>ah gotcha

<stikonas>well, we need to switch to tcc mob snapshot I guess

<stikonas>and create "simple patch" variant of patch that fixes riscv64 support (and breaks x86 support)

<stikonas>and apply it conditionally

<stikonas>the annoying thing is that recently my qemu is not working properly on my x86 machine with riscv64 code

<stikonas>or at least stage0-posix riscv code

<fossy>huh, weird

<stikonas>there are random crashes

<stikonas>really at random time

<fossy>i ran it in bwrap mode the other day with user-space emulation

<stikonas>not some reproducible

<fossy>for updating script-generator checksums

<stikonas>I'm now running native version

<stikonas>but with all nyacc pregen stuff

<stikonas>that now takes 2 weeks on visionfive2...

<fossy>Hmmm, I just re-ran it to try using user-space emulation, it immediately crashs on running mes-m2....

<fossy>only did the stage0-posix stuff when doing script-generator, no mes stuff

<stikonas>I'm on 3896c1dfc commit

<stikonas>and at the moment it is using mes to finish building meslibc

<fossy>2 weeks is insane

<stikonas>yeah

<stikonas>well, it's a slow hardware

<fossy>is that just hardware being really slow, or the riscv codegen is slow, or both

<stikonas>and especially I guess RAM is slow

<stikonas>so mes is particularly slow

<stikonas>other stuff is reasonably fast

<fossy>ahhh

<stikonas>well, 3 stage gcc 14 build is about 30 hours there

<stikonas>binutils is maybe 16 minutes

<stikonas>but mes is super slow

<stikonas>perhaps if we create unified libc it will be a bit faster

<stikonas>but there is no way around nyacc stuff

<stikonas>and that takes maybe 5 days or so

<fossy>yeah, and we aren't getting around taht in the forseeable future either

<stikonas>yeah...

<stikonas>well, there might be some faster hardware

<lanodan>And I guess it's stuck to a single CPU for much of the bootstrap?

<stikonas>well, only mes step really matters

<stikonas>mes to gcc is probably a few hours max

<stikonas>that's nothing compared to more than 2 weeks of mes

<stikonas>well, in principle mes can build stuff in parallel if we have make, but at that stage in live-bootstrap we only have kaem

<stikonas>and also need to support simple kernels for kernel bootstrap on x86 (for now)

<stikonas>so threading is not really desirable there

<pabs3>Debian is having a sprint on crossbuilds and Debian bootstrap stuff (different but related to this channel) https://wiki.debian.org/Sprints/2025/BootstrapCrossbuild

<fossy>Hmmmm

<fossy>i've been considering implementing a non-POSIX kaem-only option

<fossy>something like

<fossy>set -o multiexec 2

<fossy>that will run multiple commands in parallel

<fossy>but that would significantly help here i think

<oriansj>aggi: well building circuits that interact with VGA and PS/2 isn't hard but once you want a VT100, you end up asking for a great deal more. A 6502 with a little bit of ROM, a VGA output, PS/2 input and serial port could be used as a VT100 replacement.

<oriansj>but you'll end up having to write about 16KB of assembly to get all of the core functionality you probably want and you'll need about 2KB for just 256 PETSCII font characters

<oriansj>(8bits by 8bits per character)

<aggi>oriansj: for vga-out relatively fast memory is needed, just a side note

<aggi>although for most trivial scenarios, a 9pin matrix plotter could be considered as stdout too

<aggi>otherwise, for assembly programming, i placed 16bit x86 real-mode on todo, a decent german-language book exists

<aggi>it's only 10Euros on amazon, i just didn't buy it yet, since i've got no time for it

<aggi>i dislike buying books, if i got no time

<aggi>with the current situation, such book is better kept safe inside an amazon store house than inside an appartment i fear i couldn't pay for in a few month

<aggi>and i've received just another blackmail from bureaucracy yesterday

<aggi>i'll try to finish cleanup of the hotfix overlay for a complete fork of it, that supports tinycc/static-linking/musl-libc/linux2.4

<aggi>x86 had the benefit over 6502, i got a practical use case for it, that is re-writing linux2 bootcode for support with as86 (to avoid binutils)

<oriansj>aggi: well the speed of RAM required is relative to the number of pixels on the screen. (640x480@60hz only requires 25.175Mhz and one can get 256K of 12ns SRAM on Mouser for $1.44)

<oriansj>(although if one goes the dual port RAM route, it gets more expensive)

IRC channel logs

2025-02-08.log