Hacker News Reader

Comment by jeffbee | Hacker News Reader

Yeah but who, other than the person responsible for the firmware that boots the system, cares? These simplifications will have zero observable benefits to you. They won’t save a lot of die space or cost.

The complexity of the far past is so small that it is inconsequential today. The PS1 was implemented in spare die area of the PS2’s USB controller. Time marches on and die space becomes free.

View on HN

The OS cares, sadly. When the OS, running one one CPU, instructs another CPU to start (which happens — your system boots into your OS and also resumes from suspend with only one CPU running OS code), it sends a message called SIPI to that CPU. The CPU responds by running OS code, in real mode, at an address <1MB. So the OS needs to find valid memory below 640kB that doesn’t conflict with any other horrible legacy use.

Also, the “LA57” 5-level page table design has a little whoopsie: you can’t switch between 4 and 5 level page tables without exiting paged mode entirely.

While all true, obviating all this has no material impact on the user.

I care. I want to learn the entire thing I'm using, which means I appreciate things that are simpler and faster to learn. You can say I am a stupid or irrational person not worthy of consideration for wanting this but I am who I am and I want to spend money on computers that cater to me.

Do you want a computer architecture that replaces and obsoletes everything you've previously learned or one that evolves and adds new features on top?

Either depending on the situation.

Then you are obviously running OpenBSD on ARM.

In that case you should probably not look at x86 at all. It's one of the most convoluted architectures out there, especially because it lugs all of that legacy stuff along.

When people say "who cares?" they generally mean "what non-vanishingly-small percentage of people care?" and I think that's still an unanswered question!

It very similar to chip die space - modern technologies are so complex that to learn how 8086 works is a very small effort compare to learning how the latest intel CPUs work. And emulation of older generations is a small part of this complexity.

I'd argue that 16-bit mode is conceptually more complicated than modern 64-bit modes, at least for userspace. 64-bit mode has a single flat address space (FS/GS are just opaque offsets into this address space), memory-mapped I/O, and a single system call trap instruction. 16-bit mode has segmentation, I/O ports, multiple trap instructions (and call gates!), address space wraparound...

Learning useful things is fun, learning useless things is unpleasant, so in some sense it's more effort.

While working on not always pleasant stuff at paid job as a hobby I sometimes learn 'useless' stuff from the past. For me on average old technologies looks simpler (though not without quirks) and more interesting to learn while modern ones often look over-complicated.

Just to clarify - I don't think that Intel should retain 16bit mode, but don't think removing it would make a big difference.

> The PS1 was implemented in spare die area of the PS2’s USB controller.

This really confused me until figured out you weren't talking about the IBM PS/1 and PS/2.

I don't think they are. IBM PS/2 was more than a decade before USB.

But then, the PS2 console didn't have USB either, so I'm not sure what they're talking about.

> The PlayStation 2 also features two USB ports

https://en.wikipedia.org/wiki/PlayStation_2

PS2 had 2 USB ports on the front, did it not?

Yeh and the original had a FireWire port too!

You're right. I guess I never noticed because they didn't use it for the controllers.

True that it's invisible to end-users, but it's still a pain in the ass to people writing OSes. Lowering the barrier to entry even a little bit will be appreciated by hobbyists.

How so? The bootloader already runs in long mode with UEFI and it also takes care of bringing up other cores so this is not really a problem in my experience.

Linux still needs to use a Startup IPI to bring up other CPUs, which starts them running in 16-bit mode at an address under 1MB.

Having a fully 64-bit way to bring up other CPUs would simplify that.

UEFI doesn't really take care of bringing up the other cores. There's a way to get access to them, but you have to give them back to UEFI before exiting boot services, so that doesn't really help your kernel. You still need to do the SIPI into x86-16 code to really take control of the AP cores.

Even the new way (that isn't actually implemented AFAIK) just SIPIs into long mode code, it doesn't use the UEFI multicore stuff.

From a hobbies point of view I'd actually argue the opposite. The nice thing about the old stuff (Ex. the 8259 PIC support they're removing here) is that it's much simpler to get going. They have very large limitations, but those don't matter when just starting, and they serve as a good stepping stone and learning opportunity before eventually moving on to the modern and more complicated stuff. Additionally if you're using a bootloader then the bulk of this is already solved for you anyway.

The modern stuff is only more complicated because it had to be built around and on top of dozens of dead civilisations under it.

This is the simplistic explanation.

I think that besides that, some people are paid for complexity. That would justify the evolution of SW in the last 10 years.

> The PS1 was implemented in spare die area of the PS2’s USB controller

Whoah, that is WILD. Any info about where I can learn more about this?

https://www.copetti.org/writings/consoles/playstation-2/

Under heading “I/O”

It sounds more like the I/O firmware was running on dedicated PS1 hardware:

https://www.theguardian.com/technology/2013/dec/12/ps4-and-x...

> The PlayStation 2, meanwhile, had the original PlayStation chipset built in, so it ran pretty much any PSone title – and when that chip wasn't being used for backwards compatibility it doubled as an input/output processor, which was pretty canny.

I can't find anything claiming this. This is literally the first time I have ever seen this claim.

The original fat PS2 including majority of the PS1 hardware physically in the machine. More and more of it got offloaded to pure software emulation with later model revisions.

I, too, would like to see info on this supposed "spare die space on the USB controller" claim. Because it would be really neat if true lol

https://www.copetti.org/writings/consoles/playstation-2/#io

Essentially the thicc PS2s include the PS1 chip and normally use it for IO and also for PS1 compatibility.

Reply on news.ycombinator.com