IRC channel logs

<fossy>well yes, that would imply javascript is bootstrappable, but my point is that before now, typescript was not bootstrappable

<jackdk>Yeah I'm trying to get a sense of how much closer this has brought the GLB of the set of bootstrappable languages with advanced type systems, if at all

<fossy>ahhh

<fossy>hmm, interestingly, maybe a fair bit

<fossy>(i would still hate to do any kind of systems programming in typescript, though, so it is probably not all that helpful)

<fossy>but if quickjs could be compiled with tcc, we could get typescript before gcc

<lanodan>would be kind of ironic for quickjs to not compile with tcc as both are from Fabrice Bellard

<lanodan>quickjs-2024-01-13 works fine with a tcc 0.9.27_git20250106 seed from Alpine. At least `make CC=tcc AR=ar && make CC=tcc AR=ar tests` works.

<fossy>lol, that's interesting, that means we can get typescript before gcc

<fossy>usefulness is probably incredibly limited, but interesting nevertheless

<lanodan>Do we also get Go before gcc?

<lanodan>As for usefulness… maybe as another way to script the bootstrap process? Like how I thought few times about picking up the lua stuff from Oasis Linux as lua is a bit better than shell sometimes.

<matrix_bridge><cosinusoidally> The duktape JS VM is pretty solid and can be compiled with a stock tcc-0.9.27. Only supports ECMAScript 5.1 + typed arrays though (plus a couple of ES 6 features). I'm able to run my whole tcc_bootstrap_alt bootstrap path under duktape (and vice-versa, the bootstrap chain is able to bootstrap up to duktape). Duktape doesn't seemed to be maintained anymore though, the commits seemed to stop last year.

<matrix_bridge><cosinusoidally> mujs is also pretty good if you only need ES 5.1 (without typed arrays).

<matrix_bridge><cosinusoidally> https://github.com/cosinusoidally/tcc_bootstrap_alt/blob/master/m2min/M2_simple_asm.js is a heavily cut down version of M2-Planet that I converted to JS. It's self hosted and can be compiled by various JS VMs and C compilers. It can't yet be compiled by a stock cc_x86/M2-Planet, but the process of getting it working under cc_x86/M2-Planet would be pretty trivial (in theory my js_to_c.c program might...

<matrix_bridge>... already be able do it but I haven't checked).

<matrix_bridge><cosinusoidally> The currently maintained version of quickjs does check it can build under tcc with it's CI https://github.com/quickjs-ng/quickjs . It uses some recent mob version though.

<matrix_bridge><cosinusoidally> I have considered porting mujs to a simplified dialect of C (since it's quite a bit smaller than quickjs, and mujs is already in a fairly conservative dialect or almost ansi C).

<matrix_bridge><cosinusoidally> * of

<oriansj>gtker: Knight architecture is big endian (and it is supported in M2-Planet+mescc-tools)

<oriansj>stikonas: %0x12345678 is output in the endian form which is passed to M1 (or the implicit default for M0) x86 =? '78 56 34 12', knight => '12 34 56 78'

<oriansj>so %### is always the correct way to create a 32bit integer in M2-Planet ! and @ should only be used if one explicitly needs an 8 or 16 bit integer

<oriansj>doing !# !# !# !# is a surefire way to hit an endian problem later on.

<oriansj>evrial: you probably want to look at aggi's work it avoids GCC entirely.

<oriansj>janus: the simplest to bootstrap typed language is assembly (just most assemblers treat it all as a bag of bytes but there is nothing stopping proper type checking on every instruction)

<oriansj>The next simplest to bootstrap typed language is C

<oriansj>cosinusoidally: that would be neat to see.

<oriansj>might even make the Zig people happy

<oriansj>and for the simplest to bootstrap web experience: BBS (just need an serial port modem) and a working terminal; probably something one could extend builder-hex0 to support

<oriansj>there are even wifi modems for those not willing to go completely retro: https://github.com/stardot/esp8266_modem

<aggi>evrial: so far i've only published the linux-2.4 kernel fork

<aggi>otherwise avoiding gcc/g++ and full support for tinycc with static linking is both alot of work and too feasible to accomplish

<aggi>currently i am syncing the tinycc/static-linking/linux24/musl-libc system profile against latest upstream - almost done

<aggi>last time i had time for sync/update was summer 2022, almost three years ago, that's how much work this was

<aggi>so far all builds pass compile-time, the system boots, and alot of runtime testing remaining on todo

<aggi>besides, alternative toolchain support with tinycc too establishes a baseline to switch to any other toolchain if desired (cproc/qbe etc.)

<aggi>i'm still maintaining this mess within a fully forked portage tree, but this needs a re-write for any other packaging which would not depend on python

<aggi>the idea is i can keep a fully forked portage tree that supports cross-compilation to a few ISAs, support for gcc47, support for either linux2 abi or linux5 and simplyfies dependency tracking

<aggi>and of cause swapping toolchain to tinycc for x86, those tasks are complete, except a little regular cleanup/maintenance needed

<aggi>bad news is, i would have preferred to retain portage, because no other system integration framework exists that could cover the complexity involved

<aggi>but it is not feasible to keep portage/python self-hosting themselves for future development

<aggi>hence a system-integration re-write for bootstrappable type packaging is mandatory, not optional with tinycc toolchain

<aggi>furthermore linux2 ABI with musl-libc introduces a few limitations, yet i do not see a realistic chance to support any later or "better" kernel than linux-2.4 with tinycc

<matrix_bridge><gtker> oriansj: So the correct output would really depend on what the underlying type is? I'm guessing a char array or struct of 8 chars wouldn't need to be "endian aware" for knight?

<oriansj>gtker: well strings don't have endian properties; ascii strings are big endian on all architectures.

<oriansj>and char arrays are just strings that may or may not be null terminated.

<oriansj>but a struct of 8 chars would be in the order defined by the compiler and it isn't architecture specific.

<oriansj>but for the sake of simplicity M2-Planet lays out the struct in memory in big endian order for all architectures.

<oriansj>Only integer and pointer words have endian properties and M1/hex2 handle those architecture specific details so that M2-Planet doesn't need to.

<matrix_bridge><gtker> oriansj: So "struct { char a; char b; char c; }" would have a at offset 0?

IRC channel logs

2025-03-12.log