Thread

Making portable my unportable transputer C compiler

74 points · 11 comments · nanochess

Loading the complete thread in the background. This saved snapshot is available now. Refresh

RodgerTheGreat · 1790225357 · focus · HN ↗
It's always a delight to read about your projects, Oscar. Every program is a jewel.
initramfs · 1790225853 · focus · HN ↗
how does a debug file output 8GB+? Is it running for minutes/hours? Or is it in a format that uses a lot of rich text? I would assume a text file in hex or unicode wouldn't use very much.. Is there a way to create intervals of log files so they have a cap on the size?
1. nanochess · 1790227205 · focus · HN ↗
  It is a simple debugger log in the transputer emulator (enabled by compilation option) which outputs each instruction executed so far, around 70 bytes per line displaying the 3 registers, the stack pointer, the instruction pointer, and the disassembled instruction.
  The emulated C compiler processed a whole file ccvars.c before getting stuck in ccinter.c (this is the 5gb mark, approximately 78 millions of instructions executed). I stopped the process as soon as I saw it was stuck, but the emulator is fast, and I got extra 3 gb in the log. All this happened in less than two minutes.
  1. vanderZwan · 1790231135 · focus · HN ↗
    Another reminder of how easy it is to forget how ridiculously fast computers are these days (especially when you're not writing stuff close to the metal).
    1718627440 · 1790249629 · focus · HN ↗
    And how ridiculously slow software is. Unless you are doing bulk processing most task should be ready in milliseconds.
    vanderZwan · 1790251286 · focus · HN ↗
    In terms of throughput, absolutely.
    In terms of latency... well... we also could do a lot better there, but as I understand it, even if you do your best to cut away as much software bloat as possible, it gets really hard to improve beyond a certain level because the hardware stack itself is so much more complex and layered compared to the old days.
    initramfs · 1790257938 · focus · HN ↗
    Latency can be reduced with removing the memory management-as with uclinux- <a href="https://github.com/EI2030/FemtoTX/blob/gh-pages/uclinux_introduction.pdf" rel="nofollow">https://github.com/EI2030/FemtoTX/blob/gh-pages/uclinux_intr...
    But chips today are much larger and are basically a cruise ship or an aircraft carrier- bigger with more work than a bike. <a href="https://youtu.be/oE4cbIP5ieQ?si=h1I51dWw5w-OulVs" rel="nofollow">https://youtu.be/oE4cbIP5ieQ?si=h1I51dWw5w-OulVs
    1718627440 · 1790263224 · focus · HN ↗
    Actually latency is way less of a problem, if the input is buffered, as you can just type ahead.
    vanderZwan · 1790264920 · focus · HN ↗
    I think we're talking about different interpretations of the word "latency", both valid. You are thinking more about UI freezes and missing input, right?
    I meant "time between input and visible change on screen", or lag between writing on a tablet and the screen or eink showing the drawn line. It's not really as crucial when typing, but especially for writing or drawing on a tablet low input latency is the difference between getting in a real flow state or not.
    initramfs · 1790267703 · focus · HN ↗
    Latency is subjective, but yes, I was referring to GUI latencies mainly. System design is increasingly more important when building new alternatives to existing architectures. x86, ARM are much larger chipsets than before, but smartphones do not really need a single operating system for making phone calls and browsing Youtube. What I'd like to see is more low latency devices that can compartmentalize applications based on power consumption and speed requirements. Thinks like a notepad, calculator, and SMS app do not require Android 17, which, on my newest phone, takes over 2 minutes to reboot.
    E-ink has had some improvements- I'm acquainted with the developers of this project: <a href="https://www.crowdsupply.com/modos-tech/modos-paper-monitor" rel="nofollow">https://www.crowdsupply.com/modos-tech/modos-paper-monitor
    Refresh rate is only one component of the system- an integrated display controller can lower the latency, and of course, the choice of computer affects the speed as well. Their choice to go with USB-C Alt is a good idea.
NooneAtAll3 · 1790256953 · focus · HN ↗
> After another half-an-hour I found that my malloc function always returned the same address!!! Wow! An unexpected bug in my operating system. When the memory space is full, the malloc routine simply fails to return a NULL pointer.
don't you love it when your investigation finds bugs in completely unrelated part of the system?

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.