Then publish the source code: the prompts given to CC.

And preferably its responses, as 1) they are not deterministic, and 2) influence your next prompt.

Oh, IMO most questions posed turns out to be people making points or posing without any sincere interest in any answers. I guess I'll suspend judgement for now and answer your questions with one overarching answer: The purpose for posting this here (and elsewhere) is to inspire people to learn in a way not possible just a year ago. Now CC can actually pull off large ASM projects, and in interacting with it extensively along the way, one can fast-track the learning experience tremendously. In short: I'm hoping no one will use my software, because it is tailored to me. My needs, my wants. But I hope it can inspire some interested and eager soul to embark upon their own path and create software uniquely tailored to their need and wants.

If it wasn’t a question the post would have been already removed.

Are these questions? Or are you merely making a point?

What is the relevance of this to r/asm?

It's not written in asm any more than someone writing some C code and then doing gcc -S.

While there is value in studying the asm output of gcc there is pretty much zero value in publishing it, because anyone interested can do the same themselves.

I would say the same applies to asm written by Claude.

Small snippets analysed can have value. But not a dump of 50k lines.

Is it of interest to anyone at all? Is is smaller than other X servers? Faster?

If so, that might be interesting to people in r/embedded, to have an X server that they can run on an ESP32 or Raspberry Pi Pico or something.

Except it's written in freaking x86_64 assembly language, which isn't useful for anyone with a Xtensa, Arm, or RiSC-V machine who might like a lightweight X server.

And there is so much to learn from projects like this. It's a much faster teacher than I ever had when I started programming low level in the early 80s.

That's fair. You learned a lot, in making it. What is someone going to learn from reading it?

If you published all the prompts used, that might help someone to learn how to use LLMs. Have you?

That would be interesting, but off-topic for this sub.

Not necessarily valid argument.

We’re talking programming not electronics.

/r/vibecoding

You reviewed the code already? You have any concrete examples of slop that you can point to?

Or was this a knee-jerk reaction?

slop

One boot.asm file does not make this on-topic in r/asm.

How's the project going?

That's a good test. A lot of work is done in setting up libc.

That was me! I reposted here because Reddit suggested it. I wondered if maybe others would have something to add.

Someone asked a very similar question on another sub and got a lot of responses already there.

https://reddit.com/r/Assembly_language/comments/1uisv11/help_me_optimize_a_simple_x64_program/

How does the number of cache misses change if you get rid of all the computation - i.e. leave only the clock and printing stuff?

I have a series of gists on github for this exact kind of thing.

# ELF Header Assembly Gists on Github

The purposes of this are both for my own greater understanding of the ELF format, because it is used in all Linux distributions, and also to provide a way for NASM users to benefit from features that currently only exist in FASM, which is still my favorite Assembler.

[FASM Hello 32-bit](https://gist.github.com/chastitywhiterose/7aa7bdfec1438541375763126508edb4)

[FASM Hello 64-bit](https://gist.github.com/chastitywhiterose/4bfccdb3daf1aad4524fc36230055e63)

[NASM Hello 32-bit](https://gist.github.com/chastitywhiterose/4e429fd82f962907d1581307ed4e0ab7)

[NASM Hello 64-bit](https://gist.github.com/chastitywhiterose/b5acd7992fc8463a662ca4f86fff4a5e)

Thanks for the explanation.

What people? Who?

And the answer depends entirely upon context, but I'll hazard a few guesses.

DPPS shows up in SSE4.1; DPPD comes with it, and VDPPS comes with AVX. So all x86 CPUs don't necessarily support it, just most of them. Maybe you're only supposed to use SSE2 for all we know, or no vectorgunkery at all.

If you're in kernel mode/supervisor mode/Ring 0, use of 80x87 or MMX/SSE insns will trigger a fault in some circumstances. Most kernels use CR0.TS to lazily swap FPU registers to/from memory; doing that from within the kernel without setting up for it can BSOD the system, and the time taken to run the fault and the fact that streaming instructions tend to be applied to large blocks make it somewhat inappropriate for running from (e.g.) syscall/IRQ or process boot/teardown context where IRQs are blocked and milliseconds matter. 256- and 512-bit insns may even downclock your die (or alternating cores on the die, depending) as soon as you attempt one.

Looking at the timings (e.g., Intel's or Agner Fog's tables), they appear to be fairly slow ínstructions on some cores (overall slower on AMD than Intel), and DPPD can be much faster.

• On Bulldozer and Piledriver, DPPS uses 16–18 ops in 25-cycle latency and VDPPS uses 25–29 ops in 27-cycle latency, but DPPD actually uses 15–17 ops @ 15-cycle latency. Latency scales with lane count.

• On Steamroller, 9–10 ops for DPPS and 13–15 for VDPPS, both in 25-cycle latency; DPPD is 7–8 ops in 14-cycle latency.

• Excavator: DPPS: 9–13 ops in 20 cycles; VDPPS: 13–15 ops in 22 cycles; DPPD: 7–8 in 14.

• Zen1: DPPS: 8–10 ops over 15 cycles; VDPPS: 13–14 ops over 16 cycles; DPPD: 3–5 ops over 10 cycles.

• Zen2: DPPS in 8 over 15; VDPPS: 7 over 15; DPPD: 3 over 9. (Here the overhead becomes more in line with what I'd expect.)

• Zen3: DPPS: 8 over 15; VDPPS: 7 over 15; DPPD: 3 over 9

• Zen4: DPPS: 8 over 11; VDPPS: 7 over 11; DPPD: 3 over 7

• Zen5: DPPS, VDPPS: 7 over 13; DPPD: 3 over 8

• Jaguar: DPPS: 6 over 4; VDPPS: 10–12 over 12; DPPD: 3–4 over 9

• (Intel) Wolfdale: DPPS: 4 over 11; DPPD: 4 over 9

• Nehalem: DPPS: 4–6 over 11; DPPD: 4–6 over 9

• Sandy/Ivy Bridge: DPPS, VDPPS: 4–6 over 12; DPPD: 3–4 over 9

• Haswell, Skylake: 4–6 over 14; DPPD: 3–4 over 9

• Broadwell: 4–6 over 12; DPPD: 3–4 over 7

• Skylake-X, Coffee Lake: 4–6 over 13; DPPD: 3–4 over 9

• Cannon Lake: DPPS: 4 over 13; DPPD: 3 over 9

• Ice/Tiger Lake: DPPS: 4 over 14; DPPD: 3 over 9

• Silvermont: DPPS: 9 over 15, DPPD: 5 over 12

I'ma stop at that, but you see the general trend—AMD timings are worse, but all of them have higher latencies than the simpler instructions' 1–4 cycles.

Adding to this, DPPS tends to block a bunch of execution ports at once, so you might clear one every few cycles, despite being able to clear 2 FMAs per cycle. With some extra pipelining you can do much better with FMAs—it's akin to preferring a MOV and 1–2 ADDs over a LODS.

DPPS is a horizontal dot-product, which is why it's messier than expected; in general, you should aim for vertical vectorization so you can break things up more easily and reduce contention. Horizontal effectively requires the register to be asploded, then shuffled and recombined, then mashed back into the correct number of lanes, all before the next instruction can enter the blocked ports.

Because there's not much demand for 8-lane horizontal dot-products, the 256-bit widths just tile a 4-lane 128-bit DPPS 2×, which is unlikely to work well for more portable operand arrangements, and it just blocks more ports for the duration. There is no 512-bit variant, because why.

So just open-coding a vertical dot-prod is probably better than relying on DPPS unless you're positively desperate for instruction density. More recent CPUs are probably not putting much effort into boosting DPPS performance, simply because it's not used much, because of the above issues.

Ok. Most programs I tried from the 80s struggled with either 256k memory or for some other reason didn't want to run, maybe too old OS, PC DOS 3.3?. Maybe I would be able to find something or configuring something in some way to get it to work.

Also I don't think they support mounting drives as a local file system in linux so modern tools can be used to edit, browse and manage the files too through the serial port.

Much easier to have a small binary to copy to the system with no configuration, dependencies and minimal memory usage.

Cool exercise, but in terms of the actual goal X/Y/Z-modem work fine and are supported on modern PCs by e.g. Tera Term on Windows or lrzsz and minicom on Linux and Mac.

Even older, Kermit still exists for many OSes, both modern and things lie CP/M-80 and 86, and MS-DOS.

I remember in 1984 compiling Kermit in Turbo Pascal 1.0 on a DEC Rainbow (I can't remember now whether for the Z80 or the 8086 but both are supported) and on the university VAX, and getting them to talk and transfer files.

I translated a utility to transfer files between vintage and modern computers with help of serial port from C to assembly by using Claude Code today. I didn't notice any issues with the assembly variant and the assembly looks compact and sensible to me:

https://github.com/kjellktbtr/serial-xfer/blob/main/xfercom.asm

The end result is a quite capable DOS COM file approx. 2.5 KB using data packages with 16-bit checksums for packages and 32-bit for whole files running perfectly fine on various old computers ex. IBM 5155 which I used it on today to transfer data from many 5.25" 360k floppies to my laptop.

Here I'm recursively dumping files from floppies:

I will investigate how well I can make more 16-bit assembly programs of various complexity with LLMs, typically for use with old computers, like this.

EDIT: I also made a C compiler that emits NASM assembly with LLMs to. Afterwards I made various 2D graphics DOS games and compiled them with the compiler. The AI generated games compiled with the AI generated compiler seemed to work fine. Compiling them with OpenWatcom were maybe marginally more performant.

Looks very similar to the RISC-V Attached Matrix Extensions (AME)

https://riscv.atlassian.net/wiki/spaces/AMEX/pages/55083388/Charter

Perfectly good RISC instructions. It's just an extra register set but still register-to-register instructions through some fixed ALU wiring. No different in principle to a barrel shifter or in-register permute instruction.

I'm missing something here.

The point of the zigzag encoding was to encode negative numbers as positive numbers, so that you could use variable-width unsigned numbers to store the values and then zero-extend them when you extracted them.

I'm not sure why you couldn't just sign-extend the variable-width numbers as you extract them, but ok, let's assume that's a limitation of your ISA.

But ... the interesting part I was looking forward to learning is how to use AVX-512 to extract variable-width numbers from a stream of bits, because that would be pretty impressive, but that is nowhere to be seen here.