abainbridge

The ancient artefact described also featured in a Jonathon Blow lecture, as an example of an engineering skill we lost for 1600 years: https://youtu.be/ZSRHeXYDLko?t=402

> I think the op is far too pessimistic about code size and performance

My code gen is definitely worse than TCC! But I think modern CPUs see all my redundant register-register moves and just treat them as a no-ops. Probably performance isn't much worse than TCC. But currently I can hardly compile a program complex enough for a meaningful comparison to be made.

> I think the viewpoint that your're missing is: how do I make sure the machine code means the same thing as the source code?

Ooo, no. I already have an AST. When writing the code gen for a node type in the AST, I normally start by typing a few lines of C into godbolt that exercises the same kind of thing represented by the node type. I try a few different compilers and optimization settings and look at what gets generated. I pick an approach that looks simple and good enough. Then I ask an AI to assemble the instructions I see the compilers using. I like to ask an AI to do this because it will explain what all the bits do in the instruction encoding and it is less error prone at reading the ISA docs than I am. The description from the AI might prompt me to ask things like, "what if the jump target doesn't fit in the 32-bit immediate" etc.

All I was claiming was that this is easier than generating code for a byte code of my invention, partly because I don't have to invent a byte code and partly because I can use existing tools to help, eg disassemblers/debuggers to check my output or compilers to give me ideas on how to convert C-like statements into machine code.

I don't have any IR at the moment. I'll have a think about what benefits that might bring.

The reason I posted my project under this top level thread is because I'm interested in Small Programs and Languages. My experiment is in what I can remove from a language implementation to make it simpler. Adding a dependency on LLVM is the opposite of what I had in mind :-)

There are many reasons I'm writing it in C but mainly because I like C.

I didn't know about the Appel book. I'll take a look. Thanks.

I feel like the way we write about compiler design could be reduced in complexity too. I read the blog posts by Nora Sandler and they did a great job compared to "the Dragon book" (confusing now because her book has a dragon on the front too). But we still ought to replace phrases like "lexical analysis" with "character grouping" (credit to Sam H Smith for forcing that one into my brain).

> What I understand from that is, byte code is portable while machine code isn't.

This is an area I want to explore. It seems to me that it is less true than it used to be. Nowadays all desktop or server class CPUs support 8, 16, 32 and 64-bit integers. And they all have at least 10 general purpose registers. As a result, the same code generator works for them all. As it stands, my code generator calls functions like emit_indexed_load, emit_conditional_jump etc. There are currently 26 of those functions.

So far I have only implemented them for x86_64 machine code output. But writing versions that output ARM64 or risvc doesn't seem hard. I expect I'll find small problems which will cause me to have to tweak the set of CPU features my code gen depends on.

As for generating bytecode being easier than x86_64 machine code, I disagree. There are lots of tools for validating x86_64 machine code (ie disassemblers). There aren't any for a bytecode I might invent. And I can ask an AI how to generate x86_64 machine code to do an indexed load. I immediately get the answer. I don't have to think about how to make an efficient bytecode encoding.

TCC is partly what motivated me to try. But I want to get closer to lower the Kolmogorov Complexity. I'm happy to sacrifice C compatibility. In fact I'm happy to sacrifice much of the power of C. And I'd be happier with code that was somewhat slower.

And the original TCC code is not easy to understand. It is a lot cleverer than I can cope with!

Hah. I won't pretend I'm not motivated by the same forces as many lost souls before me. But if my language turns out anything like Lisp, I'd be upset.

I'm interested in making a really simple compiled scripting language. I don't understand why most scripting languages compile to bytecode and then interpret that. This requires the following steps:

1: Design a bytecode. 2: Write a compiler. 3: Write an interpreter.

It seems like it would be simpler to not bother with 1 and 3 and instead use machine code as the bytecode. A side benefit is that programs will run faster.

I think it is easy to generate machine code for x86_64, ARM64 and risvc64, as long as you don't mind it being 3x larger and slower than an optimizing compiler would generate. It ought to be easy because it is possible to only target the common subset of features these architectures support.

I made a start, https://github.com/abainbridge/mortar, but haven't got much past being able to compile and run a Fibonacci sequence generator. I have no experience with language design or compiler implementation. I was somewhat gobsmacked when the fib generator ran 380x faster than an almost identical looking Python program.

Any comments or suggestions, including, "that's a bad idea, you will fail because of XYZ", or, "save yourself the effort, here's one I wrote earlier..."?

Hadn't seen Cozette before. Its lovely. Ta.

One I made. Available here: https://github.com/abainbridge/deadfrog-lib/blob/master/src/...

Has 7 sizes ranging from 6x10 pixels to 16x30. The larger ones are a bit rubbish. Only covers Latin-1.

That's awesome. Now what I want is an animated version that shows how the bugs lines change over time.

I prefer bitmap fonts for coding / terminal. My monitor is 100 DPI and I like to cram as much on screen as possible. Here's a comparison of a bitmap font vs Nordwand https://gist.github.com/abainbridge/a4b2647ea91e661a7576417b...

I know I'm a bit weird, but the internet is full of weird people. It seems strange to me that nobody is interested in bitmap fonts these days.

What I really want is a hand anti-aliased bitmap font which prioritizes sharpness.

I want to see the same graph but for number of CVEs introduced. ie, when we find a CVE, find out which kernel version introduced it. This would only be useful for kernel versions that were a few years old, so we'd have had time to find most of the CVEs. But it'd still be interesting.

Yes. I don't really understand why Zig gets more attention than dlang. It seems that it is more to do with the personality of the authors, rather than the technicalities. I get the impression that Walter is more laissez-faire, while Andrew is more single-minded. I'm grateful to the contributions both have made.

Another point I liked was that there was, apparently, an influential book called Structured Programming, whose content was so universally agreed upon, that all programming became Structured Programming. Nobody needs the book anymore.

There are many well documented cases of rapid evolution: a population of African elephants became 50% tuskless at birth in a single generation, urban fox anatomy diverged from rural, frogs in the Chernobyl Exclusion Zone turned black, the Peppered Moth turned black in the industrial revolution.

I'd have no idea how to find him. But I think it'd be a fruitless task anyway. I'm sure they'd have no memory of what, to them, was a moment as mundane as any other that day. I've definitely had people recount a shared experience to me, reminiscing about how profound it was, and me having no idea what they're talking about.

I think I have an observation that defies the info on that page. That page was written around the time that STEVE (an aurora related phenomenon) was first named. https://en.wikipedia.org/wiki/STEVE

I mention this because in the 1990s, while at uni in St Andrews, Scotland, I remember a trip to the astronomy observatory one evening. There was a peculiar cloud overhead - whitish purple, tube shaped and shimmering. I asked the astro professor what it was. He said, "Its a cloud" and showed no further interest. I took a photo. When I got the film developed and photos printed, you could see bright colours either side of the tube. I've always wondered a) what it was and b) why that astronomy professor was an astronomy professor when he had no interest in what the universe had to reveal to him.

I now believe it to have been a STEVE. I've still got no insight into the mind of the astro professor.

For a few years I worked in the team that wrote software for an embedded audio DSP. The power draw to do something was normally more important than the speed. Eg when decoding MP3 or SBC you probably had enough MIPS to keep up with the stream rate, so the main thing the customers cared about was battery life. Mostly the techniques to optimize for speed were the same as those for power. But I remember being told that add/sub used less power than multiply even though both were single cycle. And that for loops with fewer than 16 instructions used less power because there was a simple 16 instruction program memory cache that saved the energy required to fetch instructions from RAM or ROM. (The RAM and ROM access was generally single cycle too).

Nowadays, I expect optimizations that minimize energy consumption are an important target for LLM hosts.

> seems like x86 and the major 8bit cpu's had the same speed, pondering in this might be a remnant from the 4-bit ALU times.

I think that era of CPUs used a single circuit capable of doing add, sub, xor etc. They'd have 8 of them and the signals propagate through them in a row. I think this page explains the situation on the 6502: https://c74project.com/card-b-alu-cu/

And this one for the ARM 1: https://daveshacks.blogspot.com/2015/12/inside-alu-of-armv1-...

But I'm a software engineer speculating about how hardware works. You might want to ask a hardware engineer instead.

Those aren't the only resources. I could imagine XOR takes less energy because using it might activate less circuitry than SUB.

> Code is formal, and going from C to assembly is deterministic.

OK, this is the main thing. Going from C to assembly is not deterministic in a sense because different compilers can produce different output. But the behaviour of the generated assembly is always the same. This isn't true of a spec.

> A spec is an envelope that contains all programs that comply. Creating this spec is often going to be harder than writing a single compliant program.

This perfectly explains the feeling I had when, 20 years into my career, I had to start writing specs. I could never quite put my finger on why it was harder than coding. My greater familiarity with coding didn't seem a sufficient explanation.

When writing a line of spec, I had to consider how it might be interpreted in the context of different implementations of other lines of spec - combinatorial nightmare.

But code is just a spec as far as, say, a C compiler is concerned. The compiler is free to implement the assembly however it likes. Writing that spec is definitely easier than writing the assembly (Fred Brookes said this, so it must be true).

So why the difference?

I wasn't comparing the two studies. I was just asking what the first sentence of the abstract of study 1 meant when it appears to be a false statement given study 2's result. Usually this is because I don't understand something and someone around here explains what I'm missing.

The abstract begins, "Growing evidence supports early eating to control appetite and energy balance". What does that mean? My unskilled reading of it is that there is recent evidence that eating breakfast helps with weight loss. But I'm confused because there was a 2019 meta-analysis that found that eating breakfast does NOT help with weight loss. https://www.bmj.com/content/364/bmj.l42

> try using obscure CPUs

I tried asking Gemini and ChatGPT, "What opcode has the value 0x3c on the Intel 8048?"

They were both wrong. The datasheet with the correct encodings is easily found online. And there are several correct open source emulators, eg MAME.

In the UK the wholesale price was about £80/MWh in 2025. The retail price was about £270/MWh + a standing charge. If you factor in the standing charge, an average user paid about £344/MWh. So the cost of generation was only about 23% of the retail price. I believe the green levies + CfDs accounted for about another 15% of the retail price.

Does this mean that if generation was free, and there were no green policy costs, our electric would still be expensive?

edit: "Network and Distribution" appears to contribute about 23% of the retail price. I guess green energy increased that cost because wind/solar are more spread out and sometimes off-shore.

Doh. Thanks.

We're seeing this galaxy as it was 280 million years after the Big Bang. But the universe didn't become transparent to photons until 100 million years after that (https://en.wikipedia.org/wiki/Recombination_(cosmology)). So that's impossible. Who's wrong, Recombination theory or this paper?

Or have I missed something?

Yep, I think it is. The point is there's almost no history of oral peptides, other than stomachs destroying them.

FTA: "So to summarize the state of the art in oral peptide delivery: there are exactly two FDA-approved products that use permeation enhancers to get peptides into your bloodstream through your GI tract. Both achieve sub-1% bioavailability. Both required over a decade of development, thousands of clinical trial participants, and hundreds of millions of dollars."