tyfighter

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.

Another amazing piece of gaming and art by an incredible, dedicated community. I'm thoroughly enjoying it so far, and I've still got a long way to go.

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.

Modern x86 implementations don't even do the XOR. It just renames the register to "zero".

I don't know which strains credulity more:

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 don't even know what a clicker game is or why one would be stimulating.

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."

This just in - cherry-picked shitty C++ code behaves shittly. Who cares?

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.

No, you're not getting it. The reverse engineering itself is obviously extremely difficult work, but it's the work of an individual or at best a small team. Reverse engineering work only provides existence proofs of security issues, mostly singular instances. Taken to its extreme, some reverse engineers believe this means that all memory unsafe software needs to be rewritten. The sheer amount of software written in C or C++ dwarfs the size of the reverse engineering community in amounts I can't even fathom.

Actually, I have changed, and I've changed corporate C/C++ MANY times to satisfy compiler upgrades. It is always just shitty code. It's never something insidious. Bugs happen. It probably wasn't your intention, but you've made UB sound pretty awesome.

Aside from the contrived examples in the paper, the rest are bugs. The kernel exploit was a just a lack of a NULL check; another bug. Bugs are going to happen, and they're going to have unpredictable consequences. What does that have to do with the language and undefined behavior? These are all just more evidence of needing to know what you're doing if you're going to write code at this level, but really not because the vast majority of people aren't writing code where bugs in the form of crashes or security exploits will have serious consequences or can't be fixed.

What universe are you working in where you think ANY of that is actually true? In the land of reality where I live and work (I work in hardware), I'm not constructing philosophical prose about well-defined systems. This is another bad faith argument where undefined behavior is made out to be some house of cards. I hate to break it to you, but every computer and all it's software you've ever used is a monument to the glory of undefined behavior, because people just didn't worry about it.

I keep finding myself angry about the recent (some number of years) focus on C and C++'s undefined behavior. I have been writing C and C++ for 27 years, 16 years professionally, and despite all the scary implications, I do not understand why ANYONE cares. I do not get it. This is yet another article that goes on and on about nonsensical situations that are just shitty code. Integer overflow? Who cares? Unless you're targeting a specific compiler and architecture, it doesn't matter. C and C++ have footguns. Everyone knows that. Who cares?

I am anger commenting, because I'm just sick of this, but this article still says nothing to convince me that any of this matters.

If we're being honest, no country will.

ITIF’s report found that, quite frankly, this stuff is hard. > "Fabricating semiconductors is perhaps the most complex manufacturing activity humanity undertakes," wrote the study authors.

These processes are trade secrets requiring years of expensive iterative R&D. You can't skip over years of internal knowledge building by just throwing money at it. Just because the ruling/capital class wants all this chip fabrication infrastructure doesn't mean civilization is obligated or even capable of making it happen.

Of course they realize that, because that's not what the article is about. The problem being described is that the distribution of talent/intelligence across the problems civilization is facing is uneven. The author's perspective is that individual interests and pay/profit incentives bias the distribution towards fun boom/bust industries (e.g. video games/VR/entertainment), and more critical industries may be losing out on this talent as a result. These are problems that capitalism can't naturally solve, because not every problem needing to be solved can be crafted into profit driven market. More than a "critique of capitalism", the author has noticed his industry is filling up with engineers/competition.

It may look like the person in the demo videos is having to step very carefully because they don't feel very stable underfoot, but in actuality they have to pee really badly and they're desperately searching for a bathroom.

But from the pictures, the Maia 100 is also using CoWoS packaging. That will be necessary for any new HBM chip.

You use ironwail (https://github.com/andrei-drexler/ironwail), and start downloading and playing maps from the sites above :).