Comment by lolcraft | Hacker News Reader

Comment by lolcraft | Hacker News Reader

I see not that many features that I like and modern processors don't have. Array bound checking would be nice, of course. And yes, not having different pools of unrelated, different-size registers, and a more RISCy opset would be very very considerate. But some of these features seem very inferior by design:

Virtual memory -- useless with 4 GB of RAM at 30$. I'm personally also a proponent of managing this kind of thing with software, since we have OS's, and with good reasons.

String instructions: became useless in terms of performance when the Pentium pipeline came along. Which was undoubtedly a good design decision.

Custom opcodes: just write an interrupt handler for INT3, or whatever INT you like. Your OS might not let you in user mode, but some might say that's a feature.

LOCK existed from the beginning of the multiprocessor era, so please don't act so smug about it. It's like saying that your submarine swims.

The paging unit of the x86 allows the presence of a tag, independent of pointers, including code/data separation. And I'm not that keen on implementing a typesystem in hardware. Extensibility and all that.

Not separating opcodes for different semantics is a bad idea. It's like overloaded operators. Who knows what you are doing, given that types are not known in runtime. I'd personally like to see assembly become a more typeless programming language, anyway.

Vector operations and such... Well, in reality, they probably would slow down the processor, compared to having many atomic instructions, RISC being faster to execute than CISC and all that.

Oh jeez... I wish I could just assume you were trolling here.

Virtual memory: This is used to give every process a flat and consistent address space. It is not just a synonym for 'swapping', and it will be around forever.

String instructions: Seriously, are you just making it up as you go along? http://www.strchr.com/strcmp_and_strlen_using_sse_4.2

Custom opcodes: Usually done via API's that have an emulation or compatability function, DirectX, OpenGL for examples.

LOCK existed: The article describes an atomic compare and write, not just a LOCK. In fact, MUTEX is implemented with the compare and exchange instruction in most OS's. http://marc.info/?t=113443157800005&r=1&w=2

I believe the no execute bit is a very recent addition to AMD64, and is not available at all on x86.

Vector operations and such: Have you not heard of MMX, SSE or even graphics cards?

Either I'm feeding a troll here, or you have no clues available to you.

If I'm not mistaken, most modern CPU architectures implement virtual memory in hardware for the obvious reason that checking every memory access with software would be very slow (essentially require running in a virtual machine) - this is not an area where the Burroughs architecture remained ahead of the times even in 1982 (at least w.r.t. Mainframes and minis). (The 68020 had a PMMU coprocessor which was included on chip in the 68030 and later. Similarly the 80386 iirc.)

Virtual memory is exceedingly slow and difficult without hardware support.

Vector operations (SIMD etc) aren't necessarily RISC vs CISC; it is orthogonal. The very notion of RISC vs CISC is practically an antiquated notion now.

Especially since modern Intel processors are mostly RISC-like inside with a CISC decoding layer wrapped around it. The difference is academic as it all boils down to similar CPU-level code and seems more dependent on the internal design of the chip than the instruction set.

"Virtual memory - useless with 4GB RAM"

So when, if ever, are we going to see it disappear? (If disks are always going to be cheaper than RAM?)

Some kernels allow you to disable swapping to disk, and others run quite well without any swap, but this the notion of "swap" still seems tightly integrated into most OS's. And I'm still seeing gimmicks like "Increase your system memory with [some catchy product name, but is actually nothing more than a multi-GB USB stick you plug in to give you more swap]."

Will we ever move beyond the concept of swapping to disk?

Swapping is a different aspect of virtual memory.

Instead what we are talking about is having each process appear to have its own memory address, where virtual addresses are translated to different pages that may or may not be backed to specific physical RAM.

So he is addressing the fact it's still difficult to have the full 4GB "addressable"?

Just trying to understand his comment.

No, the major benefit of virtual memory is simplicity for applications.

Instead of having to be aware of everything else in memory, and carefully allocating around other things and taking care not to step on each other, it can just assume that nothing else exists, and it has the whole addressable range to put things where it likes.

This isn't really true of course, it's a bit like being given a magical chest-of-drawers in which both you and your friends can use the same drawer, but every time you open it, it only has your own things inside. And behind the scenes, there's a little imp shifting stuff in and out depending on who's pulling the handle.

The virtual addressing part is the sharing of those drawers, the swapping part is if, instead of having only 4 drawers, there are now 8, or 16, or any number. If you open one of these drawers that doesn't actually exist, the imp rummages around in a bigger box in the next room, finds it, and fills whatever is meant to be there. He also sedates you if this happens, so the change appears 'instant' to you.

Because going into the other room is slow for him (and also you, but you might not necessarily notice because you're unconscious) he keeps a bunch of the most recent or most common things around close to hand on his side of the drawers so he can swap them quickly. Every time you need something that isn't nearby, he has to take something out with him to make space, and come back with the new thing.

There's a reasonable argument that this latter part (swapping) can be optional - you don't really have infinite memory like you're pretending, it's still limited to either the amount you can address, or the amount you can store in your secondary storage. And, comparatively, the secondary storage is really damn slow. But, for those occasional times when you just pass the limit, being able to handle that without crashing or the kernel arbitrarily nuking something to make space, it's useful.

This reminded me of Tim OReilly trying to explain how sed works back in the 1980's. In his case it was a monk/scribe instead of an imp. Nice work.

Is the sedation COW?

No, I was going for Page Fault[1], which, if I recall my comp. arch. lectures, suspends the requesting process until the required page has been read from disk and put in memory somewhere. So wall-clock time passes, but the process itself doesn't know about it until it resumes. Even then, I don't think it can know definitively why it was suspended - it could just as well have been pre-empted by some other task.

[1] https://en.wikipedia.org/wiki/Page_fault

Looking at the article...

"A single bit in the descriptor can be used to specify whether the array (or other segment) is actually in core or not (the 'presence bit"). Bingo! Virtual memory."

This is really swapping, not virtual memory as we understand it today. While memory protection and translation are essential IMO, I agree with other commenters that swapping is mostly obsolete.

> Vector operations and such... Well, in reality, they probably would slow down the processor, compared to having many atomic instructions, RISC being faster to execute than CISC and all that.

Vector operations are about expressing data parallelism to the processor. Parallelism/concurrency is the only thing that will save us past the end of Moore's Law. It has very little to do with fast MMX/SSE lanes.

> Array bound checking would be nice

x86 has this.

> Virtual memory -- useless with 4 GB of RAM at 30$.

No. This is wrong, even if you do bizarrely assume everyone can afford 4GB of RAM for their systems. There will always be workloads that need it.

> RISC being faster to execute than CISC

You can only prove this through benchmarks.

Reply on news.ycombinator.com