I never encountered any encryption/protection of any kind on the II (had 3 bootloaders: a simple memory loader -> a huffman tree decompressor -> another simple memory loader) and even though I got pretty far on the III I could see there being some kind of key embedded in the firmware somewhere. I was able to disassemble any .syx firmware release that came out. I wrote my own IDA Pro modules for the TigerSHARC (II) and TI-C66x (III). II took a while but I learned a lot. When the III came out I started over. I spent a lot of time reverse engineering the amp block code, but stopped about 8 years ago. Back then he wasn't even compressing the firmware yet, so it was easy.
Nice :) I did this for my Axe-Fx II and III a long time ago, but I never published any of it for fear of being sued. Really, I just wanted to learn about DSP techniques and that was enough for me.
I just can agree with any interpretation of the article's code that believes programmers should desire silent sign extension when everything about the expression and data types involved is explicitly written to avoid signedness. At the end of the day, programming languages should naturally express intent and not rely on memorization of surprise. Here, I believe that Microsoft correctly employed principle of least surprise, and that ultimately the spec is broken and because of the amount of code in existence just can't be fixed.
I think the lack of a real usable emulator for SGIs is holding back any kind of homebrew. I say this as one of the developer's that got SGI Indy emulation working in MAME. Yes, it works, but it's too slow and too old to be usable. I spent some time after the MAME effort working on a custom high performance emulator for Crimson/Onyx/Reality Engine, but I've kind of burned out again. Maybe some day if I'm really driven again, and had help. I've done most of the reverse engineering already, it's just a lot of code.
I think that if a high performance, usable emulator for some of the big systems existed I think some of the old software might be rediscovered and show up on the internet.
Hardware bugs can be found during chip bring-up within the first couple of months back from the fab, but since I've worked in this area I've never actually seen a bug that couldn't be worked around. They happen, but they're rare and I've never experienced a chip needing a respin because of a bug.
There is documentation, but it's not as well organized as you might imagine. Documentation is usually only necessary when implementing new features, and the resulting code doesn't change often. There are also multiple instruction sets as there are a bunch of little processors you need to control.
Vulkan/DX12 aren't really "low-level" APIs. They're "low overhead", and honestly, no. Their code base is just as large and complicated, if not more so, than OpenGL/DX11.
I haven't made a website of any kind since a C&C: Red Alert fan site somewhere on GeoCities in the late 90s.
I work on graphics drivers. They're hard write and even harder to debug. You have to be a huge nerd about graphics to get very far. It's a relatively rare skill set, but new, younger, nerdier people keep on coming. Most people in graphics are quiet and are just keeping the industry functioning (me). It's applied computer architecture in a combination of continuous learning and intuition from experience.
This is something I heard through the grape vine years ago, but when you're a very large corporation negotiating CPU purchasing contracts in quantities of millions, you can get customizations that aren't possible outside of gigantic data centers. Things like enabling custom microcode (and development support) for adding new instructions for the benefit of your custom JIT-ed server infrastructure. The corporate entity here is likely a hyperscaler that everyone knows.
Actually, the reason Transmeta CPUs were so slow was that they didn't have an x86 instruction hardware decoder. Every code cache (IIRC it was only 32 MB) miss resulted in a micro-architectural trap which translated x86 instructions to the underlying uops in software.
How is anyone just supposed to know that? It's not hard to find vim, but no one says, "You need to be running this extra special vim development branch where people are pushing vim to the limits!" Yes, it's fragmented, and changing fast, but it's not reasonable to expect people just wanting a tool to be following the cutting edge.
You're (they're?) not alone. This mirrors every experience I've had trying to give them a chance. I worry that I'm just speaking another language at this point.
EDIT: Just to add context seeing other comments, I almost exclusively work in C++ on GPU drivers.
1.) In the 1960s, the Air Force developed a top-secret device power enough to simulate the EMP of a nuclear blast, i.e. some form of Non-nuclear Electromagnetic Pulse device that wouldn't be developed into a weapon for a few more decades. Rather than a controlled scientific test, they then decided to secretly drive it up to an operating missile base. They proceed to set it up on a 60 foot tall portable stand without anyone at the site noticing. I guess people at the site had their AirPods in for hours while giant generators run to charge the banks of capacitors necessary to run something that huge. No one noticed anything of this happening until it was hovering over the gate, they had their rifles pointed at it, and the mad scientists behind this plan were justified in their fear that our missile launch facilities were vulnerable to EMP.
2.) In the 1960s, a UFO disabled a missile at a launch facility.
I must not be the target audience for this kind of thing, but I really don't get it. The few times I've opened HN today I've seen this at the top, and the number of points has been higher. I've opened it 3 times, and clicked the button, and some other icons showed up below. The first time I didn't open even bother to mouse over the icons, so I didn't know you'd be buying things. I closed before I got to 50 stimulations. The second time, I did hover over the icons showing up, and clicked a couple, and nothing seemed to happen other than spending stimulation, so I closed before 100. I just did this a third time as it's now over 1200 points, and I really just don't understand what is going on. What am I missing?
> The fundamental problem here is that no standardized shader ISA or even bytecode exists, and there is no material incentive for any vendor to create or agree upon one.
It's not really a material incentive issue. GPU instructions are "microcode". The instructions can contain timing and dependency information that is specific to the underlying microarchitecture. That information is not standardizable, and even if it was, it just kicks the can down the road by adding yet another shader program translation step from something "standard" to hardware specific. CPUs translate (or fetch) ISA to microcode while running, but that's a chip area cost. If every SM/CU needed a hardware ISA to microcode translator, that would be fewer SMs/CUs per GPU. My opinion is that GPUs need custom microinstruction ISAs to stay competitive with each other, and that will always require some form offline shader translation.
The BSF/BSR quirk is annoying, but I think there is a reason for it is that they were only thinking about it being used in a loop (or maybe an if) with something like:
int mask = something;
...
for (int index; _bit_scan_forward(&index, mask); mask ^= 1<<index) {
...
}
Since it sets the ZF on a zero input, they thought that must be all you need. But there are many other uses for (trailing|leading) zero count operations, and it would have been much better for them to just write the register anyway.
Yeah, I'm sure that's what anyone trying to build some kind of AI startup that's managed to acquire a small handful of A100 or even better H100s thinks too. "Those cards sure were expensive, but ethically, I'd rather the software run slower to give me future imaginary options than to get the most out the hardware I just bought."
I appreciate that HN follows the research, and have wondered if others have had the same experience as me. My mother was diagnosed with Early-Onset Alzheimer's at age 57 in 2013. The progression was slow at first, but it was a major problem for our family by 2017, and she died at 65 in 2022. My dad died of health issues seriously exacerbated by grief of what had happened. It destroyed my family. I'm still in my 30s and both of my parents are gone. This all happened during what are supposed to be the most critical years of a person's tech career. I am almost done with handling my parent's affairs, and am preparing to make major changes to my life again.
Alzheimer's is a terrible disease that is going to wreck havoc on the lives of of countless millenials/genzs as their baby boomer parent's age into it. We need to understand this disease as soon as possible.