IRC channel logs

<Googulator>oriansj: don't forget 8/16-bit type support; it's probably the biggest missing feature in M2

<Googulator>the one that caused the most headaches for unxz

<matrix_bridge><cosinusoidally> rough awk implementation of a subset of hex2 https://github.com/cosinusoidally/tcc_bootstrap_alt/blob/dev/m2min/hex2.awk . Doesn't support comments, and only supports 32 bit relative/absolute labels. To work around this I feed hex2 files through m0.awk twice (see mk_hex2_awk_full and mk_hex2_awk).

<matrix_bridge><cosinusoidally> To work around lack of comment files I feed hex2 files through M0 a second time I mean

<matrix_bridge><cosinusoidally> -files

<matrix_bridge><Andrius Štikonas> Googulator: we do have partial 8/16 bit support

<matrix_bridge><Andrius Štikonas> https://github.com/oriansj/M2-Planet/blob/5c251e67e28e0a441589b9c3f5150758b8034998/cc_types.c#L102

<matrix_bridge><Andrius Štikonas> Might be missing some corner cases

<matrix_bridge><Andrius Štikonas> But at least you can store shorter ints in structs

<Googulator>stikonas: the issue is with 8/16-bit arrays, especially writing them (we always write 32 bits)

<oriansj>Googulator: I know 8bit arrays (char* ) work in M2-Planet for both reading, comparison and writing; and pointers are always 32bits

<matrix_bridge><cosinusoidally> Pointers are always 32 bit in M2-Planet? Even on the 64 bit backends? In C ints are typically 32 bit on both 32 bit and 64 bit, but iirc M2 uses 32 bit ints on 32 bit and 64 bit on 64 bit?

<matrix_bridge><cosinusoidally> I thought it was the same with pointers on M2?

<stikonas>I think oriansj was talking about 32-bits

<oriansj>cosinusoidally: pointers on M2-Planet should be thought of as 32bit because any M2-Planet program greater than 2GB will be broken as the jumps and other behavior will be wrong.

<stikonas>well, jumps will be broken

<stikonas>but some stuff is probably outside 32-bit? itsn't it

<stikonas>e.g. stack...

<oriansj>and M2-Planet will allocate 8bytes for storing those values

<oriansj>but those are set by the kernel and not M2-Planet

<stikonas>but yes, we can't deal with large jumps

<stikonas>I think in the end on x86_64 we only use jmp32 instruction

<matrix_bridge><cosinusoidally> but you can handle 64 bit addresses for data?

<oriansj>in fact on ARMv7 is limited to 24MB for jmp limits

<oriansj>only on 64bit hosts

<stikonas>riscv is also more limited...

<stikonas>probably for same reason

<oriansj>efficient common case vs big binary support. So yeah

<matrix_bridge><cosinusoidally> https://learn.microsoft.com/en-us/windows/win32/winprog64/virtual-address-space interestingly on windows you can limit a 64 bit program to 2GB of addressable memory (which makes porting 32 bit code easier as it gets rid of a lot of pointer truncation bugs).

<oriansj>basically M2-Planet is not expected to be used past GNU Mes or TCC and creating a 24MB binary via M2-Planet+mescc-tools is just a bad idea

<oriansj>but 20MB is plenty of space for a pretty huge C compiler to be written

<stikonas>also integer literals in M2-Planet are limited to 31-bit

<stikonas>hence we have to do tricks like https://git.stikonas.eu/andrius/stage0-uefi/src/branch/main/posix-runner/posix-runner.c#L15

<stikonas>(0x60000082 + 0x60000000)

<oriansj>right now the biggest thing M2-Planet makes is M2-Mesoplanet (1.3MB)

<oriansj>and for x86 only makes 14MB of binaries total

<stikonas>hmm, how come M2-Mesoplanet is so big

<stikonas>that's even more than mes...

<matrix_bridge><cosinusoidally> $ ls -lh usr/lib/gcc/i686-linux-gnu/7/cc1

<matrix_bridge>-rwxr-xr-x 1 root root 22M Apr 15 2018 usr/lib/gcc/i686-linux-gnu/7/cc1

<matrix_bridge>phew

<oriansj>stikonas: good question, I am not sure

<oriansj>perhaps a difference in M2libc (has more architectures and dumb syscalls) and meslibc (has more functions and clever syscalls)

IRC channel logs

2024-09-16.log