IRC channel logs

<notgull>The issue with C isn’t the pointers, the issue is the context sensitive syntax and weird sensitive rules

<notgull>What you really need is a syntax that can be lexed from Assembly easily as well as a non-pathological assembler

<notgull>Forth and LISP fit these criteria but fail later on

<notgull>Although if it were up to me I’d be looking for ways to avoid builder-stage0.

<mwette>Without `typedef' C is context free.

<matrix_bridge><Jeremiah Orians> Well the core of C has a pretty simple lexer (not as simple as s-expressions but still relatively small as seen in cc_reader.c. https://github.com/oriansj/M2-Planet/blob/master/cc_reader.c#L239

<matrix_bridge><Jeremiah Orians> But once you start adding bits to support C preprocessing it starts getting ugly https://github.com/oriansj/stage0/blob/master/stage2/High_level_prototypes/cc_x86/cc_reader.c#L123

<matrix_bridge><Jeremiah Orians> mwette: a rusty C might be a nice idea to explore.

<matrix_bridge><Jeremiah Orians> Have 4 stacks: function call stack; base/bound stack; variable stack; exception stack.

<matrix_bridge><Jeremiah Orians> As closures are a poor man’s objects and objects are a poor man’s closure. We can skip both by having structs and function pointers.

<matrix_bridge><Jeremiah Orians> Have explicit allocation (instead of malloc/calloc; have HEAP_ALLOC, STACK_ALLOC and GC_ALLOC)

<matrix_bridge><Jeremiah Orians> Algol 68 style tagged unions

<matrix_bridge><Jeremiah Orians> Vectors could be defined as struct {TYPE _TYPE; uint64_t length; uint64_t capacity; pointer DATA} (and similarly for arrays and strings)

<matrix_bridge><Jeremiah Orians> (Or type[capacity] DATA instead of a pointer)

<aleksi>Hey, I'm hitting an interesting bug in M2 on aarch64. It seems that with two 32-bit signed values a, b in local variables, computing `a < b` works wrong. It seems to be a combination of two things: the values are loaded from the stack frame with `ldr w<r>`, which is technically right, but performs zero-extension. But then the comparison is computed with `cmp x<a>, x<b>`, which is basically the same as doing an unsigned co

<aleksi>mparison in the end, due to zero-extension.

<aleksi>A guess the quickest fix for this would be to have `ldrsw` in place of `ldr` for signed loads on aarch64, but I'm not sure if that would have implications elsewhere, since it goes against the ABI convention

IRC channel logs

2026-09-26.log