I also wonder if the vaunted Canadian healthcare system plays a role. When advances in medical science are something you automatically expect to benefit from personally if you need them, they look a lot better than when you have to scramble just to cover your bills for what we have now.
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.
That's absolutely correct, unless of course you count the fact that you can't create a CISC CPU with just as many registers that can be used to store data, manipulate data, etc sans a cache hit as a RISC CPU given the same die size.
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 had hundreds of registers to store the stack frames. There is some smart overlapping of stack frames so that functions could pass by reference straight through registers. When you look at the depth of the function call stacks in some GUI systems, those are needed.
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.)
Then there would be separate addition/multiplication and vector operation units, so that separate instructions could be processed independently. Modern CPU's are also deeply pipelined to around 14+ stages - every one of the classic four Fetch, Read, Execute, Write stages has been parallelized with pre-lookup, abort and bypass stages, so that means that around 100+ instructions can be in flight at any time. Then the results written back into registers have to be synchronized. So there are register scoreboards to keep track of dependencies. To keep track of all those and to guarantee program execution safety, extra instructions have been added to implement mutex's and thread barriers in hardware.
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.
Another difference was that RISC CPU's would implement complex instructions like floating-point division in microcode rather than in hardware logic.
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.
They're not the only ones. The IBM mainframes have long been VMs implemented on top of various microcode platforms.
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.
The main differences between RISC and CISC, as I recall were lots of registers and the simplicity of the instruction set. Both the Intel and zSeries CISC instruction sets have lots of registers, though.
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, althoug
In Soviet Russia Conservatives Obama *you*. FTFY. Beowulf cluster of Hitlers. Step 4 - Profit. MyCleanPc you insensitive clod. Global warming. Intertubes. Nuke them from orbit.
Did I miss anything?
Natalie Portman and hot grits, or is that too last millenium?
My story: Been using Linux and BSD heavily since the 90s. I don't really care if you spell "restart foo" as "/etc/init.d/foo restart", "/usr/local/etc/rc.d/foo.sh restart" "service foo restart", "systemctl restart foo", or just "pkill foo && foo".
you are speaking of different "dialects", it's a matter of apparence, not substance, a disk can be accessed as/dev/hda,/dev/sda or/dev/disk0, but the important thing is that you *can* access the disk via a special file in the dev directory...
not the case of systemd approach, that is "change everything at a substantial level, just because"
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....
You are obviously demonstrating that you have no personal experience with systemd; systemd is a collection of tools
Could somebody then either rename the collection of tools to have a name that doesn't sound like the name of a UN*X daemon, or rename the tool in that collection that some Linux distributions run in process 1 to something other than "systemd", so that people don't confuse the collection of tools with the init-process tool in that collection? This might fix at least some of systemd's public relations problem.
(I mean, srsly, Apple's made some changes to "traditional UN*X", but they don't designate mDNSresponder or the ASL-version of syslogd or... as parts of the "launchd" project.)
And servers - do they still care about the servers?
Depends on which kinds. Macminis get used as servers. They are suddenly doing well with the MacPro. They have an excellent small business server product. Also remember they just recommitted to enterprise. Apple is very hard to read on this, but I think in general they would want to be able to support a server quickly not have a long lag.
I wouldn't hold my breath waiting for Apple to have 128-core enterprise servers, however.
I think your objection is that they maintain all this stuff and distribute it as part of the same source tarball.
Is there some compelling reason for them to do so - and to stick "systemd-" in front of the names of a number of daemons? If nothing else, it could be bad public relations if it gives people the impression that the program whose name is "systemd" performs functions that, in other UN*Xes, are done by programs launched through the init process.
> The more you change that, the less interchangeable the various Unixen become.
A disadvantage for the user, an advantage for those selling linux systems.
Canonical tried to make Linux unique by messing up the UI level, RH tries with the most important item after the kernel, PID 1.
The hardware makers are all too happy about it because they don't like unix tools and ideas born in the 70s that offer old hardware an indefinite operative life.
As opposed to ideas born in the '80's, such as "every UN*X variant gets to do a few things differently from most of the other variants"; it sounds as if you're saying that Linux is reimplementing that idea amongst Linux distributions.:-)
Except for the fact that you're talking about nuance.
Are the differences between BSD init+init.d scripts, System V init+SV init scripts, launchd and launch daemons/agents, Solaris SMF and whatever it uses, and systemd just "nuance"?
Well, that link speaks of people from Elbrus, and this page from Eltechs' web site says "The MCST Binary Translation Team has 200+ man-year experience in developing binary translators. They implemented a number of x86 to e2k (a Russian CPU)". The "e2k" is probably the Elbrus 2000, for which they implemented an x86-to-native binary translator. The MCST (Moscow Center of SPARC Technologies) referred to by the Elbrus 2000 page is probably the same MCST referred to by the Eltechs page.
Modern developer do not deal with memory allocation anymore, but they work at a level of abstraction with design paradigms which are every bit as complex to grasp than hardware architecture.
I'm not the person who said that "Java schools are a menace" and that "you're really missing something if you don't have a good mental model of computers at the machine language level, and if you've never done any "bit bashing" (working with unsigned ints as arrays of bits, not as numbers)." - and then spoke of "pointer-array equvalency" as if it were a fundamental concept of how computers work at the low level rather than as an over-simplified description of a quirk of C and its derivatives (they're not equivalent - array-valued expressions evaluate as a pointer to the first element in the array in some, but not all, contexts),
Eww Octal??? My gosh, the PDP-11 is the purest of the pure! It is the excuse, the reason for Octal to exist!
No, octal was a much better fit for machines such as the PDP-6/PDP-10, PDP-5/PDP-8, and other multiple-of-6-bits-word-size machines. It worked well for PDP-11 instructions, not so well for PDP-11 data words if you cared about the individual bytes in the word.
It's defined right there in the code as "char foo[1024];"
Yeah, I was thinking of another example I'd been working on when I wrote the answer; sorry about the minor brainfart.
In any case, yes, it is, indeed, a pointer to char in the code that I wrote, so just replace "int" with "char" in my answer and the answer still applies.
I know why they are different, but why don't you tell me why they are different and I'll see if you're right.
They're different because, in main, foo is an array of 1024 chars, and thus has a size of 1024 bytes, whilst, in bar, foo is a pointer to int and, unless you're running on a C implementation with 1024-byte pointers (I know of none, although I do know of implementations with 2-byte, 4-byte, 8-byte, and 16-byte pointers), its size won't be 1024 bytes.
And about superscalar processors, which make opcode timing a bit less straightforward. And pipelining and instruction prefetching and branch prediction and caches and instruction scheduling and....
Slashdot Mirror
They say
I also wonder if the vaunted Canadian healthcare system plays a role. When advances in medical science are something you automatically expect to benefit from personally if you need them, they look a lot better than when you have to scramble just to cover your bills for what we have now.
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.
Canadian health care has its problems, but it's still better than most of the alternatives.
Better than, say, the health care systems in the UK, Germany, France, Spain, the Netherlands, Switzerland, Taiwan, etc.?
That's absolutely correct, unless of course you count the fact that you can't create a CISC CPU with just as many registers that can be used to store data, manipulate data, etc sans a cache hit as a RISC CPU given the same die size.
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 had hundreds of registers to store the stack frames. There is some smart overlapping of stack frames so that functions could pass by reference straight through registers. When you look at the depth of the function call stacks in some GUI systems, those are needed.
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.)
Then there would be separate addition/multiplication and vector operation units, so that separate instructions could be processed independently. Modern CPU's are also deeply pipelined to around 14+ stages - every one of the classic four Fetch, Read, Execute, Write stages has been parallelized with pre-lookup, abort and bypass stages, so that means that around 100+ instructions can be in flight at any time. Then the results written back into registers have to be synchronized. So there are register scoreboards to keep track of dependencies. To keep track of all those and to guarantee program execution safety, extra instructions have been added to implement mutex's and thread barriers in hardware.
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.
Another difference was that RISC CPU's would implement complex instructions like floating-point division in microcode rather than in hardware logic.
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.
but then there is the fact that most RISC's use same registers for both FPU and integer
With the minor exceptions of Alpha, PA-RISC 1.x and 2.0, POWER/PowerPC/Power ISA, MIPS, and SPARC.
They're not the only ones. The IBM mainframes have long been VMs implemented on top of various microcode platforms.
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.
The main differences between RISC and CISC, as I recall were lots of registers and the simplicity of the instruction set. Both the Intel and zSeries CISC instruction sets have lots of registers, though.
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, althoug
In Soviet Russia Conservatives Obama *you*. FTFY. Beowulf cluster of Hitlers. Step 4 - Profit. MyCleanPc you insensitive clod. Global warming. Intertubes. Nuke them from orbit. Did I miss anything?
Natalie Portman and hot grits, or is that too last millenium?
My story: Been using Linux and BSD heavily since the 90s. I don't really care if you spell "restart foo" as "/etc/init.d/foo restart", "/usr/local/etc/rc.d/foo.sh restart" "service foo restart", "systemctl restart foo", or just "pkill foo && foo".
I spell "restart autofsd" as
which is the same way I spell "start autofsd in the first place".
you are speaking of different "dialects", it's a matter of apparence, not substance, a disk can be accessed as /dev/hda, /dev/sda or /dev/disk0, but the important thing is that you *can* access the disk via a special file in the dev directory ...
not the case of systemd approach, that is "change everything at a substantial level, just because"
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....
Just want to point out that SMF may have been Slowaris' demise.
Or not.
Just saying there's a correleation.
Two data points (or, if Solaris isn't dying, one data point) and you declare a correlation?
One great thing about Unixen is how they share common interfaces.
Because they're all exactly the same at the system/process management level. There is no such thing as SMIT or SMF or two different flavors of traditional init or....
You are obviously demonstrating that you have no personal experience with systemd; systemd is a collection of tools
Could somebody then either rename the collection of tools to have a name that doesn't sound like the name of a UN*X daemon, or rename the tool in that collection that some Linux distributions run in process 1 to something other than "systemd", so that people don't confuse the collection of tools with the init-process tool in that collection? This might fix at least some of systemd's public relations problem.
(I mean, srsly, Apple's made some changes to "traditional UN*X", but they don't designate mDNSresponder or the ASL-version of syslogd or... as parts of the "launchd" project.)
It prevents regular user programs from masquerading as system services, which usually sit below port 1024.
Seriously, once you have personal computer on a network, "reserved ports are available only to root" is, as noted, cargo-cult security.
Depends on which kinds. Macminis get used as servers. They are suddenly doing well with the MacPro. They have an excellent small business server product. Also remember they just recommitted to enterprise. Apple is very hard to read on this, but I think in general they would want to be able to support a server quickly not have a long lag.
I wouldn't hold my breath waiting for Apple to have 128-core enterprise servers, however.
Launchd is the young whippersnapper on the block. Solaris has had daemon administration for years.
I.e., since before late April 2005, as that's when OS X 10.5 Tiger, the first release with launchd, came out?
I think your objection is that they maintain all this stuff and distribute it as part of the same source tarball.
Is there some compelling reason for them to do so - and to stick "systemd-" in front of the names of a number of daemons? If nothing else, it could be bad public relations if it gives people the impression that the program whose name is "systemd" performs functions that, in other UN*Xes, are done by programs launched through the init process.
> The more you change that, the less interchangeable the various Unixen become.
A disadvantage for the user, an advantage for those selling linux systems.
Canonical tried to make Linux unique by messing up the UI level, RH tries with the most important item after the kernel, PID 1.
The hardware makers are all too happy about it because they don't like unix tools and ideas born in the 70s that offer old hardware an indefinite operative life.
As opposed to ideas born in the '80's, such as "every UN*X variant gets to do a few things differently from most of the other variants"; it sounds as if you're saying that Linux is reimplementing that idea amongst Linux distributions. :-)
Except for the fact that you're talking about nuance.
Are the differences between BSD init+init.d scripts, System V init+SV init scripts, launchd and launch daemons/agents, Solaris SMF and whatever it uses, and systemd just "nuance"?
I wonder if they are some of the same people as these (reading about theiur team it does not sound unlikely): http://www.embedded.com/electronics-news/4397737/X86-emulation-coming-to-ARM-processors
Well, that link speaks of people from Elbrus, and this page from Eltechs' web site says "The MCST Binary Translation Team has 200+ man-year experience in developing binary translators. They implemented a number of x86 to e2k (a Russian CPU)". The "e2k" is probably the Elbrus 2000, for which they implemented an x86-to-native binary translator. The MCST (Moscow Center of SPARC Technologies) referred to by the Elbrus 2000 page is probably the same MCST referred to by the Eltechs page.
So, yes, probably the same people.
Modern developer do not deal with memory allocation anymore, but they work at a level of abstraction with design paradigms which are every bit as complex to grasp than hardware architecture.
I'm not the person who said that "Java schools are a menace" and that "you're really missing something if you don't have a good mental model of computers at the machine language level, and if you've never done any "bit bashing" (working with unsigned ints as arrays of bits, not as numbers)." - and then spoke of "pointer-array equvalency" as if it were a fundamental concept of how computers work at the low level rather than as an over-simplified description of a quirk of C and its derivatives (they're not equivalent - array-valued expressions evaluate as a pointer to the first element in the array in some, but not all, contexts),
Eww Octal??? My gosh, the PDP-11 is the purest of the pure! It is the excuse, the reason for Octal to exist!
No, octal was a much better fit for machines such as the PDP-6/PDP-10, PDP-5/PDP-8, and other multiple-of-6-bits-word-size machines. It worked well for PDP-11 instructions, not so well for PDP-11 data words if you cared about the individual bytes in the word.
None of these or any other internal arcana of c have anything to do with designing algorithms or programming computers.
Go tell that to the person who argued that programmer should become totally comfortable with bit-bashing, with pointers and pointer-array equivalency, and so on. "Pointer-array equivalency" (or "array-valued expression conversion to pointer-valued expression in most contexts") definitely counts as "internal arcana" of C and related languages.
Um, perfesser? It's a pointer to a char.
It's defined right there in the code as "char foo[1024];"
Yeah, I was thinking of another example I'd been working on when I wrote the answer; sorry about the minor brainfart.
In any case, yes, it is, indeed, a pointer to char in the code that I wrote, so just replace "int" with "char" in my answer and the answer still applies.
I know why they are different, but why don't you tell me why they are different and I'll see if you're right.
They're different because, in main, foo is an array of 1024 chars, and thus has a size of 1024 bytes, whilst, in bar, foo is a pointer to int and, unless you're running on a C implementation with 1024-byte pointers (I know of none, although I do know of implementations with 2-byte, 4-byte, 8-byte, and 16-byte pointers), its size won't be 1024 bytes.
They haven't learned about opcode timing
And about superscalar processors, which make opcode timing a bit less straightforward. And pipelining and instruction prefetching and branch prediction and caches and instruction scheduling and....