There's "the alternatives" and there's "the alternatives worth considering". The latter category excludes the developing countries in question, as well as the US. Hopefully the people in charge of health care in Canadian governments (federal and provincial) are looking at the alternatives in the latter category to see what they can learn from them.

That isn't answering the question I asked.

The question I asked was "You can't trade off, say, transistors used for registers (especially given that the bigger processors do register renaming, so you have more hardware registers than the actual RISC/CISC instruction set provides) for transistors used for some other purpose?"

I said nothing about keeping all the same functionality, if by "functionality" you mean, for example, "on-chip caches of the same size" and "same number of hardware registers including ones used for renaming of the architected registers" or "complexity of the branch prediction hardware" or .... Yes, there may be tradeoffs you have to make in how you use your transistors, but if the benefits of the additional registers outweigh whatever performance benefits you lose by reducing the size of other functional units by however much the additional registers require, that might be the right tradeoff to make.

OK, that's probably using "memory indirect postindexed mode". Addressing modes that complex are something some CISC processors had, but not others; x86 is much less complex (scaling, but no memory-indirect or auto-increment/auto-decrement), and S/3x0 even less complex than that (no scaling, just double-indexing).

How often was that addressing mode used, in practice? Was it used often enough that you saved enough code space that you could make the I cache smaller?

Then presumably, if the anonymous submitter was Canadian, they were one of "most Canadians", and offered his or her hypothesis about the attitudes towards science and the Canadian health care system because either 1) they didn't pay attention to the EU results or 2) they assumed that European countries are like the US in their heath care systems.

Or perhaps they were a typical Amurrican and made the same silly assumptions.

In any of those cases, if the second paragraph of their submission had been eaten by a grue, nothing of value would have been lost - heck, something would have been gained. (I mean, my knee-jerk reaction would have been to blame "We depend too much on science and not enough on faith" on Amurrican religiosity, but, absent any data on whether the more-religious countries in the EU have a sufficiently-high level of agreement with that assertion as to drag the EU average down, even with those countries in the EU that are less religious than Canada, I wouldn't wonder too hard about that one.)

That if you think a packet coming from a privileged port is coming from a program run by a user whom you can trust, that's only true if you can trust everybody who's plugged a personal computer into your network or you can ensure that nobody on any of those computers gets to run programs with sufficient privileges to get to use privileged ports. (Remember that this subthread started with a mention of privileged ports, which I do not consider one of the Great Ideas In Network Security.)

When I gave this Connectathon talk, somebody asked about the

MacOSX automounter daemon
Launched in user’s session by launchd - exits when idle
Runs with user’s credentials

slide, with "ZOMG WHAT IF THE NFS SERVER ONLY SUPPORTS MOUNT REQUESTS FROM A PRIVILEGED PORT!!!!1111ONE!!!!", I forget what I said, but, in retrospect, I wish I'd said "oh, we're going to remove the root-only restriction on privileged ports", and taken delight in any pathetic squeals of terror that resulted.

(We ended up, for other reasons, running automountd as root in a privileged session, so that wasn't an issue.)

Who's "you" in this context? I am an admin user on my Mac; if that means that plugging my machine into your network would terrify you, then you'd better somehow make sure that never happens. Don't expect me to care about your problem.

So? Most of us USans are mostly exposed to the US system as well, but that's not an excuse for being clueless about the rest of the world.

I.e., if "gee, our health care system doesn't let people who aren't well off get no health care" is offered as an explanation for why Canadians are less likely than people in the European Union to say that "We depend too much on science and not enough on faith.", whoever offers that explanation really needs to start looking at European health care systems, or, at least, to get a by-country breakdown of the EU figures and see whether there's any correlation between having a health care system that lets the poor fall through the cracks and believing that "We depend too much on science and not enough on faith."

(And if they weren't even bothering to care about countries other than the US when concocting that hypothesis, they need to get out more.)

Or, to put it another way, I refuse to give a damn whether it's what you're most exposed to, as it's completely irrational to care; if I were Canadian, I'd be embarrassed to see a fellow countryman acting as if the US was the only other significant country on the planet and as if the EU didn't exist.

They say

but it sounds as if they're comparing the Canadian system for paying for health care with the US system, as opposed to the systems used in for example, Western Europe.

Better than, say, the health care systems in the UK, Germany, France, Spain, the Netherlands, Switzerland, Taiwan, etc.?

You can't? You can't trade off, say, transistors used for registers (especially given that the bigger processors do register renaming, so you have more hardware registers than the actual RISC/CISC instruction set provides) for transistors used for some other purpose?

RISC processors with the letters "S", "P", "A", "R", and "C" in the instruction set name, in that order, did. The ones with the digits "8", "0", "9", "6", and "0" in the processor name also did, I think. The ones with "M", "I", "P", and "S" in the instruction set name, in that order, did not, nor did the ones with "A", "l", "p", "h", and "a" in the instruction set name, in that order, nor the ones with "A", "R", and "M" in the instruction set name, in that order, nor the ones with instruction sets having names matching the regular expression "P(ower|OWER)(PC| ISA)".

And, given that most processors running GUI systems these days, and even most processors running GUI systems before x86/ARM ended up running most of the UI code people see, didn't have register windows, no, they're not needed. Yeah, SPARC workstations may have been popular, but I don't think register windows magically made GUIs work better on them. (And remember that register windows eventually spill, so once the stack depth gets beyond a certain point, I'm not sure they help; it's shallow call stacks, in which you can go up and down the call stack without spilling register windows, where they might help.)

None of which has anything to do with RISC vs. CISC, and much of which wasn't the case when RISC processors first came out.

Actually, it's more likely to have been the other way around, unless by "microcode" you meant "software". These days, most processors whether RISC or CISC, probably do floating-point division in hardware.

With the minor exceptions of Alpha, PA-RISC 1.x and 2.0, POWER/PowerPC/Power ISA, MIPS, and SPARC.

But the microcode implemented part or all of an interpreter for the machine code; the instructions weren't translated into directly-executed microcode. (And the System/360 Model 75 did it all in hardware, with no microcode).

And the "instruction set" for the microcode was often rather close to the hardware, with extremely little in the way of "instruction decoding" of microinstructions, although I think some lower-end machines might have had microinstructions that didn't look too different from a regular instruction set. (Some might have been IBM 801s.)

So that's not exactly the same thing as what the Pentium Pro and successors, the Nx586, and the AMD K5 and successors, do.

Currently mainframe processors, however, as far as I know 1) execute most instructions directly in hardware, 2) do so by translating them into micro-ops the same way current x86 processors do, and 3) trap some instructions to "millicode", which is z/Architecture machine code with some processor-dependent special instructions and access to processor-dependent special registers (and, yes, I can hear the word PALcode being shouted in the background...). See, for example, " A high-frequency custom CMOS S/390 microprocessor" (paywalled, but the abstract is free at that link, and mentions millicode) and "IBM zEnterprise 196 microprocessor and cache subsystem" (non-paywalled copy; mentions microoperations). I'm not sure those processors have any of what would normally be thought of as "microcode".

The midrange System/38 and older ("CISC") AS/400 machines also had an S/360-ish instruction set implemented in microcode. The compilers, however, generated code for an extremely CISCy processor - but that code wasn't interpreted, it was translated into the native instruction set by low-level OS code and executed.

For legal reasons, the people who wrote the low-level OS code (compiled into the native instruction set) worked for a hardware manager and wrote what was called "vertical microcode" (the microcode that implemented the native instruction set was called "horizontal microcode"). That way, IBM wouldn't have to provide that code to competitors, the way they had to make the IBM mainframe OSes available to plug-compatible manufacturers, as it's not software, it's internal microcode. See "Inside the AS/400" by one of the architects of S/38 and AS/400.

Current ("RISC") AS/400s^WeServer iSeries^W^WSystem i^WIBM Power Systems running IBM i are similar, but the internal machine language is PowerPC^WPower ISA (with some extensions such as tag bits and decimal-arithmetic assists, present, I think, in recent POWER microprocessors but not documented) rather than the old "IMPI" 360-ish instruction set.

Depends on which version of the instruction set and your definition of "lots".

32-bit x86 had 8 registers (many x86 processors used register renaming, but they still had only 8 programmer-visible registers, and not all were as general as one might like), and they only went to 16 registers in x86-64. System/360 had 16 general-purpose registers (much more regular than x86, but that's not setting the bar all that high :-)), and that continues to z/Architecture, although the latest z/Architecture lets you do arithmetic separately on the upper 32 bits and lower 32 bits of a GPR, so for 32-bit and shorter arithmetic, you sort-of have 32 GPRs. z/Architecture also boosts the number of floating-point registers from 4 to 16.

Most RISC instruction sets had 31 or 32 GPRs (in the 31-GPR machines, one of them was always zero when fetched, and operations writing into it discarded the result); ARM had only 16 (one of which was the PC, so not really usable), but 64-bit ARM has 32.

As I see it, differences between current RISC and CISC instruction sets are:

1. RISC ISAs are load/store, meaning that arithmetic instructions are all register-to-register, whereas CISC ISAs have memory-to-register arithmetic. Splitting memory-to-register arithmetic does let you optimize "between" the memory reference and the arithmetic. However, breaking a memory-to-register arithmetic instruction into separate memory-reference and arithmetic microops lets the hardware do similar things.
2. RISC ISAs generally have more registers; that's not an inherent RISC vs. CISC characteristic, however. A CISC ISA could have, for example, 32 GPRs; at the time S/360 was designed. you couldn't just throw transistors at the problem, and, on the lower end S/360's, the GPRs were stored in a small higher-speed core memory array, not in transistorized registers, and they may have thought that assembler-language programmers and compiler writers wouldn't have been able to make much use of 32 GPRs in any case.
3. CISC ISAs may have individual "complex" instructions, such as procedure call instructions, string manipulation instructions, decimal arithmetic instructions, and various instructions and instruction set features to "close the semantic gap" between high-level languages and machine code, add extra forms of data protection, etc. - although the original procedure-call instructions in S/360 were pretty simple, BAL/BALR just putting the PC of the next instruction into a register and jumping to the target instruction, just as most RISC procedure-call instructions do. A lot of the really CISCy instruction sets may have been reactions to systems like S/360, viewing its instruction set as being far from CISCy enough, but that trend has largely died out.

Actually, I think many compilers for RISC processors will schedule instructions in that fashion. Of course, modern RISC processors may reschedule instructions in hardware, just as modern CISC processors may reschedule microoperations in hardware ("out-of-order" processors).

...which is probably implemented as a fast trap to a millicode subroutine in the aforementioned z/Architecture-with-its-own-private-GPR-set-plus-maybe-some-processor-dependent-instructions machine language. The millicode routine doesn't, as far as I know, have to save or restore any GPRs, as it gets to use its own set, and probably runs from memory that's as fast as the level 1 instruction cache rather than from the I-cache, so it might reduce I-cache misses, and can transparently differ from processor to processor in case the best string-copy or string-translate or... instruction sequence differs from processor to processor. Of course, a RISC processor could add "fast call" and "fast return" instructions that do similar GPR-set switching, and have a bigger I-cache, and the OS could make processor-specific string copy routines available, so I don't know how much those instructions would buy you.

Natalie Portman and hot grits, or is that too last millenium?

I spell "restart autofsd" as

$ cat /System/Library/LaunchDaemons/com.apple.autofsd.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>com.apple.autofsd</string>
<key>KeepAlive</key>
<true/>
<key>Program</key>
<string>/usr/libexec/autofsd</string>
<key>ProgramArguments</key>
<array>
<string>autofsd</string>
</array>
<key>EnableTransactions</key>
<true/>
</dict>
</plist>

which is the same way I spell "start autofsd in the first place".

Apparently you didn't notice that they also talked about different flavors of "process 1", such as "traditional BSD init", "traditional System V init" (well, actually, they didn't even bother mentioning the latter), launchd, SMF (which they also didn't mention), launchd, systemd, etc....