boricj

Everyone doesn't need to know SIMD. Mechanical sympathy is an important passive perk for software architects to cut down the number of reworks down the line, but I would rate benchmarking and being able to identify bottlenecks as more important everyday skills.

I'm working on a voxel space renderer homebrew for the PlayStation. I only have so many cycles to spend on rendering before it becomes a slideshow, so I count them in my hot rendering loop and parallelize work as much stuff as I can, even across memory load stalls from main RAM.

I've worked on a basic network accessory card with a STM32 MCU that is extremely overkill for what it needs to do. We haven't bothered making any performance or memory optimizations whatsoever, writing plain C++ almost as if we were on server-class hardware because we had such egregious margins.

The first question to ask is not whether something can leverage SIMD, it's whether the performance requirements are met or not (although it's far too easy to not care when it's not your hardware that's struggling...).

I've actually went far in planning and acquiring gear for my apartment, though it's a low priority task for me.

Turns out there are tons of stuff that sip power (set-up boxes, Ethernet switches, NAS...) that can either be powered directly by Power-over-Ethernet or through a splitter (DC-DC converter). That can be handled by a PoE Ethernet switch, which itself is usually powered at 54VDC, so it's also an excuse to run a homelab on 48VDC and get rid of tons of power supplies.

However, DC isn't well suited for the entire home for several reasons, mostly due to cheapness and historical reasons. For example, AC breakers are dirt cheap because arcs naturally extinguish when current crosses zero volts, whereas DC doesn't.

There are areas where DC is used. I work on telecommunication gear where nearly everything is -48VDC, but the beefy copper busbars needed to push large amounts of power through them would make a homeowner cry at the expense. Higher voltage is possible to compensate, but you enter not-safe-for-touch territory and I'm not knowledgeable about that.

Careful, or at this rate you'll end up running Linux on the Sega Saturn's 68000.

Doesn't that message date back to a time that either predates or is almost concurrent with the introduction of x86 hardware-assisted virtualization? I wasn't around playing with VMs back then, but I'm not sure that the track record of x86 virtualization 20 years ago was that great.

Some of us work with industrial SoCs, with puny in-order Cortex-A7 cores and tiny L1/L2 caches. Sometimes, you really need to optimize for the hardware and micro-architecture you have in order to hit the performance goals required and message passing isn't always the answer.

The Sega Saturn might also qualify, as its sound subsystem has a 68000 with 512 KiB of RAM. Running Linux on it might be trickier though.

The making of is well worth a read: https://phoboslab.org/log/2021/09/q1k3-making-of

If I understand it correctly, it basically boils down to copying bits from the source to the destination, in order from the least significant bit to the most significant bit. It's not equivalent to C++'s reinterpret_cast.

I'm no Zig expert, but if you want endian-dependent semantics I'd assume either @ptrCast or a packed union would do the job.

I've received a couple of emails about ghidra-delinker-extension, but I would not limit this to only emails. I've also had numerous people contacting me through GitHub issues or Discord messages over the years, with this as a topic starter.

I've had deep technical exchanges with smart people all across the world I would've never met otherwise. I've seen people using my tool for completely insane projects successfully. I've even had a data scientist from India who was inspired and motivated by my story of presenting at ACM 2025 as a hobbyist to put his work out there.

Interacting with all these people has broadened my horizons - literally going halfway across the globe in one instance. All of that happened despite me being an introvert, who hates initiating any form of social interactions with people and sounds like a raving lunatic on my blog.

Maybe I should be the one to send out more emails...

I can't seem to find a list of supported hardware (or at least hardware which is supposed to work). Will it run on a UltraSPARC T2 server? I've got one collecting dust in the basement.

It's https://boricj.net and you should read it if you like software development and Doctor Frankenstein combined.

(hint: I showcase Mad Max-driven software development on it)

Personally, a voxel space renderer for the PlayStation (Comanche terrain style rendering).

In theory, it's really not suited for this because (at least back then) this was designed for computers with:

- relatively large amounts of RAM (uncompressed color+heightmap data takes a lot of space),

- fast CPUs with data caches (it's a 2D trapezoidal walk of a top-down projected fustrum with plenty of additions, multiplications and divisions),

- memory-mapped linear framebuffers (for software rendering).

The PlayStation has none of these things: only 2 MiB of main RAM; an in-order scalar 33 MHz MIPS III processor without a FPU or a data cache, where any CPU load from main RAM stalls the pipeline for 5 cycles, multiplications have a 6 to 13 cycles latency and divisions have a 36 cycles latency; and the only way to touch VRAM is to send commands to the 2D GPU.

What it does have is 4 KiB of I-cache (direct-mapped), 1 KiB of scratchpad with no wait states and a fixed-point GTE coprocessor which is mostly geared towards projecting 3D points onto a 2D screen and not general matrix/vector processing. Meaning that if I get my hot loop within 1024 instructions (and no function calls), fit my working set+stack within 1 KiB and can pipeline the GTE for transformations and the CPU for map scanning/GPU submissions, it might just work.

So far I'm getting decent framerates (like 10-15 FPS at 256x240) with just software projection and GPU line rendering. Right now I'm wrestling with the GTE and various ways to trick it into transforming more points than it's supposed to be able to do, by looking at the fixed-hardware math equations for the various instructions and trying to fit my equations into them (doing stuff like putting relative altitude into X/Y vector registers instead of coordinates and massaging the rest of the values to get screen Y coordinates out of it).

Kind of a hardcore topic to pick for my first homebrew ever, but I craved a simpler, low-level optimization challenge as a pipe cleaner, after working on ghidra-delinker-extension for so long.

I'm only pointing out that ever since the French revolution, we have a rich history of regime change (and also of strikes and demonstrations). Some were due to external factors (like the Vichy régime during WW2) and some were bloodless (like the end of the Fourth Republic).

Us rolling the dice whenever we have a major political crisis is a meme at this point, for better or for worse we're just not the kind of people to keep the same constitution around for 250 years.

Probably because we have a well established history of regularly changing regimes. Since we overthrew royalty in 1789 we've had five republics, two empires, three monarchies and a bunch of short-lived totalitarian regimes, coups and other major political events.

If anything, the longevity of the Fifth Republic is starting to become unusual (only the Third Republic and the Ancien Régime have lasted longer). Maybe we're overdue to flip the table again as per tradition.

Isn't the information in this already largely known and documented? There have been over 30 years of tinkering, reverse-engineering work and assembly programs on the (e)z80 TI graphing calculators.

Incidentally, that lineage has finally come to an end as TI has released the TI-84 Evo-T, which uses an ARM Cortex-M core and a firmware apparently rewritten from the ground up.

I'm tinkering with a voxel space rendering tech demo as a PlayStation homebrew. After one weekend of work I'm getting decent results (like, 10-15 FPS) and I've yet to use the DMA, the GTE or even polylines primitives.

It's refreshing to dust up trigonometry and good old low-level optimization tricks. When the scratchbuffer has 1 KiB and the stack can only use a fraction of that, it makes me realize how spoiled I'm at work with the microcontrollers we have, with threads being allocated 8 KiB of stack and backtraces with over 50 functions of C++ templates on it.

The Dassault family has very close ties with the French government and defense industry. There's no doubt in my mind that if the French government gets serious and says "Jump!" Dassault would just ask "How high?"

I'll push back on that point.

The FCAS program was originally conceived as a French-German joint political initiative by Macron and Merkel. The NGF plane within it has been dead in the water for years because Airbus and Dassault can't work out their disagreements. It's a conflict between two industrial companies that's blocking forward progress, with the Airbus and Dassault CEOs duking it out across press releases and shareholder meetings.

If Dassault was a French state puppet, Macron would've strong-armed Dassault into working with Airbus on this €100 billion project by now. Yet, the French President seems to know better than to try and do that. One does not get to be basically the only major private independent defense company in a famously nationalized French defense industry during the Cold War without managing to hold the French state at arm's length, especially during the nationalization years of Mitterand's presidency.

Though your concerns about ownership of the Dutch defense industry are certainly valid, I don't see how the European defense industry could have completely avoided consolidation after the end of the Cold War, given the budget cuts to defense. The Americans went much further on that front and nowadays the lack of internal competition is causing them all kinds of problems for them.

If you want a good horror bedtime story, you can peek at OpenBIOS within the pcsx-redux tree: https://github.com/grumpycoders/pcsx-redux/tree/main/src/mip...

The commentary section starts with "The retail PlayStation BIOS code is a constellation of bugs and bad design." and it gets worse after that. There are hidden gems inside the source code comments of that simili-reconstruction.

The days of nationalized French defense companies and state arsenals have been over for quite a while. Assuming I didn't make any mistakes:

GIAT was privatized, then renamed to Nexter, then merged with German KMW to form European KNDS and now it's about to do an IPO.

All of the French aerospace industry (including missiles) bar Dassault and Thales is inside Airbus.

Arquus was bought by Belgian John Cockerill.

I could probably cite more if I dug deeper, but while we still have French defense companies like Dassault, Naval Group and Thales, a fair amount of our defense industry is no longer exclusively French owned.

And if the French government or owner starts getting uppity, you could always take a page from the Swedes and how they Kockums the shit out of ThyssenKrupp.

When you are interacting with the government for official business, what purpose is there to hide one's identity? You can't exactly not fill in your name in your tax return.

For the non-government/private business however, it is indeed a matter of privacy. France rolled out a while ago the requirement to establish the user's age when accessing porn sites. I refuse to do that.

For France it certainly is, probably because of our stubborn focus on strategic autonomy. For example, offshoring passport printing to me sounds like a great opportunity for identity theft and document forgery by people outside of your jurisdiction.

I do kinda get the China customs system example though, only because if corruption is bad enough that it's a greater concern than opsec, then you're kinda hosed anyways.

As a French person, I'm confused as to why DigiD is not a government-run project like FranceConnect is. I'm even more bewildered that an American company thought that they could take over the national identity management system of an European country, as if this was business as usual.

You could do that on PC too, if you mmap() one given block of memory at multiple locations. I think that's how PS1 emulators handle mirroring (it's been a long time since I took a peek at the innards of DuckStation).

Graphically, either play on a CRT (or with CRT filters) or use an emulator that has PGXP geometry correction to eliminate vertex jittering at higher rendering resolutions.

As for gameplay, that console has a massive library, with thousands of commercially released games (and a lot of hidden gems). I'd be surprised if any gamer wouldn't find at least one to their taste in that catalog.

Usually, that kind of stunt nowadays is done by using the lowest significant bits and masking them off when dereferencing the pointer, trading off for a higher alignment (so 4 bits gives you 16-byte alignment).

The PS1 also happens to have RAM aliasing, because there's not enough RAM to cover the entire decoding window for the RAM. I don't know the details, but I've seen PS1 executables setting their stack pointer to the end of the devkit's 8 MiB of RAM and yet they work on retail units, because it ends up at the end of the retail's 2 MiB of RAM. So theoretically, you could stuff bits in there too (and without messing with different memory regions with different cache behaviors).

Discord servers are more like a hangout place than a public forum and public invite links are like putting a key under a mat. Just because the owners of a Discord server put it on their public webpage or GitHub repository doesn't mean it's cool to spread it around willy-nilly.

There are also practical concerns. An invite link that needs to be deleted (for example due to spam abuse) means that it will no longer work. Updating all the places where that old link appeared to the new one can be impractical or impossible.

First, because personally I think it's bad etiquette to post an invite link publicly on large, open-access forums like Hacker News.

Second, because while the biggest decompilation Discord servers have effective moderation team and processes, the vast majority are just a server for a project from one or a couple of persons with <100 members joined. Such small servers don't have round-the-clock moderation or customized settings.

Third, because I regularly see phishing crypto spam posted in the smaller servers. Spreading invite links publicly carelessly increases the odds that these scammers find them and spam them.

I'd rather not post invite links here directly out of concern for spamming, but I can leave some easy-to-follow breadcrumbs.

The decomp.me Discord server invite link can be readily found on that website and in the README of its GitHub repository. It's the closest thing to a central hub of the decompilation community. You can find some invite links in its chat history by searching for "discord.gg" (including the servers listed below).

Some of these Discord servers have a #other-servers or #related-servers channel with tons of invite links to other similar Discord servers. In particular, these servers have those channels:

- PS1/PS2 Decompilation

- GC/Wii Decompilation

That way, you should be able to find dozens and dozens of Discord servers on that topic. There are still many more out there (I've joined at least six others that aren't directly reachable from the invite links inside the servers I've mentioned).

There are also other Discord servers about reverse-engineering that can contain discussions about decompilation techniques or projects.

I'm the author of ghidra-delinker-extension and these are not full lists of these projects. Here are some public projects that I'm aware of which aren't listed:

- Moon Lights 2: https://github.com/Armonte/ml2decomp

- F-15 Strike Eagle II: https://github.com/neuviemeporte/f15se2-re

I've also been in discussion with people working on decompilation projects which are private. I won't share details, but it includes both well-known games and recent games (as in, built with link time optimizations).

The decompilation community is quite decentralized, with lots of Discord servers specific to one platform or a series of games. In the case of Windows it's also heavily fragmented, as there is no equivalent to community-standard tooling like splat or dtk-decomp for that platform, although my Ghidra extension has carved itself a niche in it.

Laziness probably. Maybe there's an argument if you want to avoid branches and just blast the integer out in a fixed number of statements/instructions/bytes, but that sounds a bit fringe.

I happen to be guilty of a variant of this, where I don't bother emitting a 16-bit floating point number instead of a 32-bit one in my CBOR encoder even if it can be represented exactly. That one is laziness.