I'm not sure what issues you'd have if you statically linked the libraries in the executables (something I've had to use to get newer versions of rar to run on old versions of RHEL). Assuming of course you have dependencies resolved. Can you explain a bit further please?
If you have a dynamically-linked binary, the binary itself contains no code that makes system calls (traps to the kernel) - it contains calls to the system call stub routines, but it doesn't contain the stubs themselves, they're in the libc.so/libSystem.dylib/whatever shared library. That means that a "Linux binary compatibility" option for another OS could run Linux binaries dynamically-linked with system libraries by providing versions of those shared libraries that implements those stubs atop the other OS's native system calls (and other APIs).
If you have a completely statically-linked binary, the system call stubs are linked into the binary itself, so it contains the traps to the kernel. That means that a "Linux binary compatibility" option for another OS would have to handle those traps, when made from a Linux binary, the same way that Linux does.
This applies not only to system calls, but also to other calls whose implementations might be significantly different in different OSes. Linux's (GNU libc's) getpwnam(), for example, might read the nsswitch.conf file and determine which plugins to use to look up a user's password entry, and call those plugins itself; OS X's, however, ultimately asks the DirectoryService daemon to do the lookup, via a Mach message to that daemon. To run, on OS X, a dynamically-linked Linux binary that calls getpwnam(), the libc.so provided on OS X would have to provide a getpwnam() binary-compatible interface with the Linux one (the pointer it returns would have to point to a structure laid out the same way the one on Linux is), but it could be implemented the same way the OS X one is, by asking DirectoryService to find the password database entry. To run a statically-linked binary, it would have to arrange that, for example, an open() system call to open/etc/nsswitch.conf work, and that a "files" plugin would have to be able to open/etc/passwd and read it, etc., as the implementation of getpwnam() would be built into the executable itself.
(This is the same issue SunOS 5.x had when trying to run SunOS 4.x binaries; originally, it only supported running dynamically-linked binaries, by providing implementations of the relevant APIs that worked in the 5.x system, but eventually had to hack up stuff to support statically-linked binaries.)
> Haha. AC has a point. MacOS is the UNIX on the desktop and laptop that linux was never able to achieve.
Except MacOS isn't exactly Unix on the desktop. It's entirely something else on the desktop.
What is "Unix on the desktop", then? (If the answer involves the letter X and the number 11, that's why I use the term "UNIX+X11" - or, for the benefit of the "Linux is not UNIX" types, "UN*X+X11" - to refer to all the other desktop UN*Xes.)
The "UNIX" parts that matter to me largely involve typing stuff in response to a string ending with '$' - no, I don't like the C shell:-) - not the GUI stuff, and there are at least two pretty different flavors of the GUI stuff out there so that a third flavor, especially if it lets you use the same key sequence to copy from or paste to a terminal emulator that you use in other apps, rather than having to add Shift+ to avoid colliding with the interrupt or "literal next" character, isn't a problem for me.
It also deviates from Unix enough underneath for it to be a problem if you are trying to have it play nice with all of the other Unixen.
One requirement of being a UN*X is that there is at least one thing you do differently from all other UN*Xes to be annoying.:-) What are examples of things OS X does differently that are more of an problem than, say, things Solaris does differently, or HP-UX does differently, or {Linux,your favorite Linux distribution} does differently, or AIX does differently (saving the best for last:-))?
Make it easier to install binaries used on other *nix systems.
What makes you think Apple has any interest in encouraging the use of cross-platform apps that might, say, allow a user to easily transition away from their locked-down, proprietary environment?
Because it can also make it easier to transition to OS X for users of other desktop UN*Xes? The cross-platform apps only allow a user to easily transition away from OS X if the other platform is an adequate replacement for OS X, and the cross-platform apps are adequate replacements for the equivalent OS X apps, for them - and that might not be the case for many users other than the ones already using the other platforms.
Make it easier to install binaries used on other *nix systems. Because the pain of using Fink or DarwinPorts is too much. Both install absolutely ridiculous sized frameworks and trying to compile something when you don't have a binary is a mixture of voodoo and tears, roughly where Linux was 15 years ago. Recently I wanted to install a2ps to use some documentation scripts I created which run on Fedora / RHEL. I gave up, it was too much bother.
Meaning "make it easier to run binaries built and packaged for other *nix systems" (presumably meaning "packaged for Linux" in most cases), or meaning "make some better framework for getting and installing UN*X-utility binaries built and packaged for Mac OS X"? The former is unlikely (new executable image format support in the kernel, ld.so installed as an ELF binary in parallel with Mach-O dyld, ELF Linux-binary-compatible.so shared libraries installed along with Mach-O native shared libraries, and system call compatibility stuff if it has to support statically-linked Linux binaries), the latter might be more likely (some equivalent of apt-get/pkg_add/whatever, although what role Apple would have in maintaining the repository of packages is another matter).
Change the swapping settings to be less aggressive by default. I upgraded to 4GB to get around most of the swapping but I've found the easiest way to keep the system stable and happy is to just shut it down regularly.
To what "swapping settings" are you referring here?
A more likely concern is that the device can be used to reveal government misconduct. It was hobbyist plane-spotters who, through their observations of civilian air traffic, exposed the CIA's Torture Jet flights
If I were the CIA, and I were worried about this app, I'd make sure my extraordinary rendition flights didn't have an ADS-B transmitter. But, then, I'm not the CIA....
This according to the article seems to intercept real-time data.
If "this" refers to the app, it just picks up data from ADS-B receivers out there feeding data to Pinkfroot, as per my posting quoting TFA. If "this" refers to those ADS-B receivers, they note that said receivers cost about GBP 200, and other postings here point to a page telling you how to build an ADS-B receiver.
I infer from Pinkfroot's "Share Data" page that their apps just get the ADS-B data over the Intertubes from people who have ADS-B receivers and make the data available.
And if I'd Read The Entire Fine Article, I wouldn't have had to infer; The Fine Article says exactly that:
The firm behind the app, Pinkfroot, uses a network of aircraft enthusiasts in Britain and abroad, who are equipped with ADS-B receivers costing around 200 pounds to intercept the information from aircraft and send it to a central
database.
The app developers are intercepting identifying signals transmitted directly by the airplanes closing the gap between real-time and that delayed by a government-mandated time period
Really? Which radio in the iPhone is being used to intercept those signals? The GSM/WCDMA radio? The Wi-Fi radio? The Bluetooth radio? The GPS radio?
I infer from Pinkfroot's "Share Data" page that their apps just get the ADS-B data over the Intertubes from people who have ADS-B receivers and make the data available.
"PARC has often been criticized for its past failures to capitalize on some of its greatest inventions" How is that PARC's fault? More likely the short-sighted Xerox management that failed to see what they had?
Actually you might like it a lot. The ISA was very high level
Actually, a lot of the most-used instructions are relatively low-level. Yeah, you have all the packed-decimal, character-string, and so on instructions, but for integer, address, and floating-point work, it's your standard register-memory architecture.
and is really one of the great ISAs. Right up with VAX and ARM.
...but without the wacky addressing modes of the VAX, so it might've been a bit easier to make go faster. (Well, if you don't try to make the autoincrement/autodecrement stuff go fast except in some specialized stack cases, that might be easier.)
I thought that they had moved the System/Z to RISC emulation a while ago.
Nope. The processors directly execute the simpler instructions; the more complicated ones trap to millicode, which are special subroutines that might get their own register set to use and have some special millicode-only instructions they can run as well. (People familiar with Alpha might recognize this....)
I know they did with the old AS/400
What they did with the AS/400 was move from translating TIMI->IMPI to translating TIMI->PowerAS, so they didn't move from directly executing TIMI to RISC emulation, they moved from translating TIMI to a CISC "native" instruction set to a PowerAS RISC "native" instruction set.
Had a golf game ended differently, would we be seeing these in power macs?
Only for the PowerMacs that need to run big enterprise applications and sit in a machine room connected to disk farms with FICON.:-) These aren't Power-architecture (POWER, PowerPC, blah blah blah) chips, they're z/Architecture chips.
Couldn't deliver a fast enough processor for the price that Apple was willing to pay.
...and for the applications Apple wanted, such as, say, stuffing inside a notebook computer. They did manage to stuff a PPC 970 inside an iMac, but it never made it into a PowerBook.
Heck, I wrote a lot of 370 (and 370/XA) code in assembly on mainframes. Different call structure (no stack, although the newer mainframes have that now) and register conventions (don't ever use register 1, register 0 is right out, and return back to your caller through the address in register 14, etc.).
Those are more ABI conventions than instruction set requirements. S/3x0 might not have an instruction that explicitly treats a given register as a stack pointer, but one could choose to use a particular register as a stack pointer, as C compilers for S/3x0 and z/Architecture do. UN*X ABIs for most if not all general-register instruction sets - including x86, x86-64, S/3x0, z/Architecture, and 32-bit and 64-bit versions of various RISC architectures - do have a stack pointer, do have conventions about register use, and, at least for RISC processors, have the return address in a register (which has to be saved if you're not in a leaf routine).
RISC machines in general have a lot more registers to mess around with. Take the Itanium for example
Take the Itanium as an extreme example. Most RISC machines have 31 or 32 integer GPRs, not 128. Yeah, in a sense SPARC processors have more, but most SPARC code doesn't juggle register windows within a routine - only 31 registers are conveniently available within a routine.
With amd64 assembly, you have rax, rbx, rcx, and rdx. If you need to juggle more than that, you go to memory.
As another followup noted, no, you don't - you nominally have 16 GPRs with x86-64. Not 31, but still better than 4. Yes, some have special purposes, such as the stack pointer, but, in practice, RISC code tends to use at least one register as a stack pointer as well. I don't know offhand whether the x86-64 ABIs use rbp as a frame pointer or not; most RISC ABIs don't, I think, have a frame pointer.
Neither "CISC" nor "RISC" are instruction sets; they're classes of instruction sets. In S/360, ancestor of z/Architecture, a register-register arithmetic op has an 8-bit opcode field and 2 4-bit general register fields, for a total of 16 bits; later versions of the instruction set have added 32-bit register-register instructions. In most RISC instruction sets, a register-register arithmetic op is 32 bits - they are generally 3-operand (source 1, source 2, destination) and most RISCs have 31 or 32 GPRs, requiring 5 bits per register specifier. A load or store instruction in S/360 has an 8-bit opcode field, a 4-bit target or source register field, a 4-bit index register field and a 4-bit base register field, and a 12-bit offset field added to the index and base registers to make the memory address; later versions of the instruction set have added 48-bit register-memory instructions. In most RISC instruction sets, a load or store instruction is 32 bits.
So the CISC instructions are, by and large, no bigger than the equivalent RISC instructions, and are, in some cases, smaller. You might need more CISC instructions if you run out of registers, as you have fewer GPRs than most RISC processors, but, as z/Architecture has register-memory arithmetic instructions, you might be able to replace some load+arithmetic instruction pairs in RISC with a register-memory arithmetic instruction in z/Architecture. If you need a large offset in a load or store instruction, you might have to use a 48-bit instruction on z/Architecture, but you might be able to use a 32-bit instruction on a RISC architecture - if you're not, you'll probably need a pair of RISC instructions.
In other words, "it depends". Anybody have any actual statistics on code density for z/Architecture vs. code density for various RISC processors for the same code (e.g., code from Linux for the architectures in question)?
this chip itself could not without a major rewrite.
Well, actually, most of OS X probably wouldn't require a rewrite - it's in C/C++/Objective-C, and can run big-endian (courtesy of having worked, up to Leopard, on PPC machines, and much of it still has to for Rosetta) and 64-bit. The assembler code (in the kernel, libSystem, and some other places) would need new versions, the assembler and linker would need a lot of work (no, OS X doesn't use gas and gld), including support for z/Architecture in Mach-O, and the compiler guys might have to do some work to support Objective-C (for gcc, there's already z/Architecture support; llvm might have to have a z/Architecture backend written).
But it's still a lot of work, and the processor isn't particularly oriented towards the sorts of machines Apple sells, so it ain't gonna happen.
Actually the Power line is RISC anyway. When it is used in a ZMachine
So where are Power processors used in System z machines (except as I/O processors or blade add-ons)?
The ZSystem ISA is so high end it is almost a high level language so the translation doesn't really effect performance much at all.
OK, you're confusing System z, which is ultimately a descendant of the old System/360, and whose instruction set is a 16-GPR CISC instruction set, but not "so high end it is almost a high level language", and is directly executed by hardware plus microcode or millicode (or whatever IBM calls the millicode/PALcode/whatever in the newer processors), with System i, which is ultimately a descendant of the old System/38, and whose "instruction set" (TIMI) is an uber-CISCy instruction set that's not executed directly, it's translated to the "real" native instruction set, which used to be a somewhat 360-ish CISC instruction set (IMPI) and is now an extended form of Power (Power/AS).
The proper solution is to make programmers aware of leap seconds. There are 86400 seconds in a normal day, however there is an additional second added once or twice a year to adjust for solar time.
Wikipedia documents it quite well and programmers in modern times should be heading to wikipedia almost constantly anyway. The real problem occurs when the date/time is given in seconds since an "event" such as Jan 1, 1970. Most programmers don't know about leap seconds and I must admit, I don't generally bother calculating for them. But if it were necessary, it would be relatively trivial to do so.
Arthur Olson and company knew about them and even wrote code to calculate for them. A lot of UN*Xes out there use that code (or the glibc code, which, as I remember, was a GPLed reimplementation, reading the same file format).
Not any more, it doesn't - clicking on that link gets a complaint that your query has timed out (perhaps not surprising, given the last component of the URL - C?c111:./temp/~c1117DsjMP). However, if you go to the page for HR 1586, you can click on the link for "XXXXXXAct ofXXXX (Engrossed Amendment Senate - EAS)" to see it in HTML, or the PDF link, which has a slightly less temporary-looking URL.
He did, however, say, "No they really don't. It's why you can't run Mac OS on an IBM PC-compatible, without some major hacking.", where "they really don't" refers to "They use the SAME INSTRUCTION SET."
The statement "No, they really don't" is false; they really do run the same instruction set, for all sane definitions of "instruction set". The reasons why "major hacking" is required have nothing to do with the instruction set the processors used in Intel Macs and the processors used in PC-compatible machines support.
Slashdot Mirror
I'm not sure what issues you'd have if you statically linked the libraries in the executables (something I've had to use to get newer versions of rar to run on old versions of RHEL). Assuming of course you have dependencies resolved. Can you explain a bit further please?
If you have a dynamically-linked binary, the binary itself contains no code that makes system calls (traps to the kernel) - it contains calls to the system call stub routines, but it doesn't contain the stubs themselves, they're in the libc.so/libSystem.dylib/whatever shared library. That means that a "Linux binary compatibility" option for another OS could run Linux binaries dynamically-linked with system libraries by providing versions of those shared libraries that implements those stubs atop the other OS's native system calls (and other APIs).
If you have a completely statically-linked binary, the system call stubs are linked into the binary itself, so it contains the traps to the kernel. That means that a "Linux binary compatibility" option for another OS would have to handle those traps, when made from a Linux binary, the same way that Linux does.
This applies not only to system calls, but also to other calls whose implementations might be significantly different in different OSes. Linux's (GNU libc's) getpwnam(), for example, might read the nsswitch.conf file and determine which plugins to use to look up a user's password entry, and call those plugins itself; OS X's, however, ultimately asks the DirectoryService daemon to do the lookup, via a Mach message to that daemon. To run, on OS X, a dynamically-linked Linux binary that calls getpwnam(), the libc.so provided on OS X would have to provide a getpwnam() binary-compatible interface with the Linux one (the pointer it returns would have to point to a structure laid out the same way the one on Linux is), but it could be implemented the same way the OS X one is, by asking DirectoryService to find the password database entry. To run a statically-linked binary, it would have to arrange that, for example, an open() system call to open /etc/nsswitch.conf work, and that a "files" plugin would have to be able to open /etc/passwd and read it, etc., as the implementation of getpwnam() would be built into the executable itself.
(This is the same issue SunOS 5.x had when trying to run SunOS 4.x binaries; originally, it only supported running dynamically-linked binaries, by providing implementations of the relevant APIs that worked in the 5.x system, but eventually had to hack up stuff to support statically-linked binaries.)
> Haha. AC has a point. MacOS is the UNIX on the desktop and laptop that linux was never able to achieve.
Except MacOS isn't exactly Unix on the desktop. It's entirely something else on the desktop.
What is "Unix on the desktop", then? (If the answer involves the letter X and the number 11, that's why I use the term "UNIX+X11" - or, for the benefit of the "Linux is not UNIX" types, "UN*X+X11" - to refer to all the other desktop UN*Xes.)
The "UNIX" parts that matter to me largely involve typing stuff in response to a string ending with '$' - no, I don't like the C shell :-) - not the GUI stuff, and there are at least two pretty different flavors of the GUI stuff out there so that a third flavor, especially if it lets you use the same key sequence to copy from or paste to a terminal emulator that you use in other apps, rather than having to add Shift+ to avoid colliding with the interrupt or "literal next" character, isn't a problem for me.
It also deviates from Unix enough underneath for it to be a problem if you are trying to have it play nice with all of the other Unixen.
One requirement of being a UN*X is that there is at least one thing you do differently from all other UN*Xes to be annoying. :-) What are examples of things OS X does differently that are more of an problem than, say, things Solaris does differently, or HP-UX does differently, or {Linux,your favorite Linux distribution} does differently, or AIX does differently (saving the best for last :-))?
Make it easier to install binaries used on other *nix systems.
What makes you think Apple has any interest in encouraging the use of cross-platform apps that might, say, allow a user to easily transition away from their locked-down, proprietary environment?
Because it can also make it easier to transition to OS X for users of other desktop UN*Xes? The cross-platform apps only allow a user to easily transition away from OS X if the other platform is an adequate replacement for OS X, and the cross-platform apps are adequate replacements for the equivalent OS X apps, for them - and that might not be the case for many users other than the ones already using the other platforms.
Things I hope they change:
Meaning "make it easier to run binaries built and packaged for other *nix systems" (presumably meaning "packaged for Linux" in most cases), or meaning "make some better framework for getting and installing UN*X-utility binaries built and packaged for Mac OS X"? The former is unlikely (new executable image format support in the kernel, ld.so installed as an ELF binary in parallel with Mach-O dyld, ELF Linux-binary-compatible .so shared libraries installed along with Mach-O native shared libraries, and system call compatibility stuff if it has to support statically-linked Linux binaries), the latter might be more likely (some equivalent of apt-get/pkg_add/whatever, although what role Apple would have in maintaining the repository of packages is another matter).
Change the swapping settings to be less aggressive by default. I upgraded to 4GB to get around most of the swapping but I've found the easiest way to keep the system stable and happy is to just shut it down regularly.
To what "swapping settings" are you referring here?
A more likely concern is that the device can be used to reveal government misconduct. It was hobbyist plane-spotters who, through their observations of civilian air traffic, exposed the CIA's Torture Jet flights
If I were the CIA, and I were worried about this app, I'd make sure my extraordinary rendition flights didn't have an ADS-B transmitter. But, then, I'm not the CIA....
A load of carp? Yup, it definitely sounds fishy....
"fewer than 40 people killed by terrorists in the UK" 52 people died in the 7th July bombing attack alone, I call into question your numbers here.
OK, fine, make that "fewer than 60 people killed by terrorists in the UK". 60 << 3000 and definitely << 30,000, so his point still holds.
This according to the article seems to intercept real-time data.
If "this" refers to the app, it just picks up data from ADS-B receivers out there feeding data to Pinkfroot, as per my posting quoting TFA. If "this" refers to those ADS-B receivers, they note that said receivers cost about GBP 200, and other postings here point to a page telling you how to build an ADS-B receiver.
I infer from Pinkfroot's "Share Data" page that their apps just get the ADS-B data over the Intertubes from people who have ADS-B receivers and make the data available.
And if I'd Read The Entire Fine Article, I wouldn't have had to infer; The Fine Article says exactly that:
The firm behind the app, Pinkfroot, uses a network of aircraft enthusiasts in Britain and abroad, who are equipped with ADS-B receivers costing around 200 pounds to intercept the information from aircraft and send it to a central database.
The app developers are intercepting identifying signals transmitted directly by the airplanes closing the gap between real-time and that delayed by a government-mandated time period
Really? Which radio in the iPhone is being used to intercept those signals? The GSM/WCDMA radio? The Wi-Fi radio? The Bluetooth radio? The GPS radio?
I infer from Pinkfroot's "Share Data" page that their apps just get the ADS-B data over the Intertubes from people who have ADS-B receivers and make the data available.
"PARC has often been criticized for its past failures to capitalize on some of its greatest inventions" How is that PARC's fault? More likely the short-sighted Xerox management that failed to see what they had?
..and fumbled the future?
Mr. Singh is fighting commonsense. Fascinating. Sometimes the common's sense of an issue is distorted, while sometimes it's right on.
And maybe sometimes it takes "quite complicated scientific arguments based on even more complicated research" to figure out which of those two it is.
If you had been paying attention you would know ping also works on iOS devices too.
If you mean the command-line ping, it only works on jailbroken iOS devices.
Actually you might like it a lot. The ISA was very high level
Actually, a lot of the most-used instructions are relatively low-level. Yeah, you have all the packed-decimal, character-string, and so on instructions, but for integer, address, and floating-point work, it's your standard register-memory architecture.
and is really one of the great ISAs. Right up with VAX and ARM.
...but without the wacky addressing modes of the VAX, so it might've been a bit easier to make go faster. (Well, if you don't try to make the autoincrement/autodecrement stuff go fast except in some specialized stack cases, that might be easier.)
I thought that they had moved the System/Z to RISC emulation a while ago.
Nope. The processors directly execute the simpler instructions; the more complicated ones trap to millicode, which are special subroutines that might get their own register set to use and have some special millicode-only instructions they can run as well. (People familiar with Alpha might recognize this....)
I know they did with the old AS/400
What they did with the AS/400 was move from translating TIMI->IMPI to translating TIMI->PowerAS, so they didn't move from directly executing TIMI to RISC emulation, they moved from translating TIMI to a CISC "native" instruction set to a PowerAS RISC "native" instruction set.
Had a golf game ended differently, would we be seeing these in power macs?
Only for the PowerMacs that need to run big enterprise applications and sit in a machine room connected to disk farms with FICON. :-) These aren't Power-architecture (POWER, PowerPC, blah blah blah) chips, they're z/Architecture chips.
Couldn't deliver a fast enough processor for the price that Apple was willing to pay.
...and for the applications Apple wanted, such as, say, stuffing inside a notebook computer. They did manage to stuff a PPC 970 inside an iMac, but it never made it into a PowerBook.
Heck, I wrote a lot of 370 (and 370/XA) code in assembly on mainframes. Different call structure (no stack, although the newer mainframes have that now) and register conventions (don't ever use register 1, register 0 is right out, and return back to your caller through the address in register 14, etc.).
Those are more ABI conventions than instruction set requirements. S/3x0 might not have an instruction that explicitly treats a given register as a stack pointer, but one could choose to use a particular register as a stack pointer, as C compilers for S/3x0 and z/Architecture do. UN*X ABIs for most if not all general-register instruction sets - including x86, x86-64, S/3x0, z/Architecture, and 32-bit and 64-bit versions of various RISC architectures - do have a stack pointer, do have conventions about register use, and, at least for RISC processors, have the return address in a register (which has to be saved if you're not in a leaf routine).
RISC machines in general have a lot more registers to mess around with. Take the Itanium for example
Take the Itanium as an extreme example. Most RISC machines have 31 or 32 integer GPRs, not 128. Yeah, in a sense SPARC processors have more, but most SPARC code doesn't juggle register windows within a routine - only 31 registers are conveniently available within a routine.
With amd64 assembly, you have rax, rbx, rcx, and rdx. If you need to juggle more than that, you go to memory.
As another followup noted, no, you don't - you nominally have 16 GPRs with x86-64. Not 31, but still better than 4. Yes, some have special purposes, such as the stack pointer, but, in practice, RISC code tends to use at least one register as a stack pointer as well. I don't know offhand whether the x86-64 ABIs use rbp as a frame pointer or not; most RISC ABIs don't, I think, have a frame pointer.
For CISC you need more bytes per instruction
Neither "CISC" nor "RISC" are instruction sets; they're classes of instruction sets. In S/360, ancestor of z/Architecture, a register-register arithmetic op has an 8-bit opcode field and 2 4-bit general register fields, for a total of 16 bits; later versions of the instruction set have added 32-bit register-register instructions. In most RISC instruction sets, a register-register arithmetic op is 32 bits - they are generally 3-operand (source 1, source 2, destination) and most RISCs have 31 or 32 GPRs, requiring 5 bits per register specifier. A load or store instruction in S/360 has an 8-bit opcode field, a 4-bit target or source register field, a 4-bit index register field and a 4-bit base register field, and a 12-bit offset field added to the index and base registers to make the memory address; later versions of the instruction set have added 48-bit register-memory instructions. In most RISC instruction sets, a load or store instruction is 32 bits.
So the CISC instructions are, by and large, no bigger than the equivalent RISC instructions, and are, in some cases, smaller. You might need more CISC instructions if you run out of registers, as you have fewer GPRs than most RISC processors, but, as z/Architecture has register-memory arithmetic instructions, you might be able to replace some load+arithmetic instruction pairs in RISC with a register-memory arithmetic instruction in z/Architecture. If you need a large offset in a load or store instruction, you might have to use a 48-bit instruction on z/Architecture, but you might be able to use a 32-bit instruction on a RISC architecture - if you're not, you'll probably need a pair of RISC instructions.
In other words, "it depends". Anybody have any actual statistics on code density for z/Architecture vs. code density for various RISC processors for the same code (e.g., code from Linux for the architectures in question)?
this chip itself could not without a major rewrite.
Well, actually, most of OS X probably wouldn't require a rewrite - it's in C/C++/Objective-C, and can run big-endian (courtesy of having worked, up to Leopard, on PPC machines, and much of it still has to for Rosetta) and 64-bit. The assembler code (in the kernel, libSystem, and some other places) would need new versions, the assembler and linker would need a lot of work (no, OS X doesn't use gas and gld), including support for z/Architecture in Mach-O, and the compiler guys might have to do some work to support Objective-C (for gcc, there's already z/Architecture support; llvm might have to have a z/Architecture backend written).
But it's still a lot of work, and the processor isn't particularly oriented towards the sorts of machines Apple sells, so it ain't gonna happen.
Actually the Power line is RISC anyway. When it is used in a ZMachine
So where are Power processors used in System z machines (except as I/O processors or blade add-ons)?
The ZSystem ISA is so high end it is almost a high level language so the translation doesn't really effect performance much at all.
OK, you're confusing System z, which is ultimately a descendant of the old System/360, and whose instruction set is a 16-GPR CISC instruction set, but not "so high end it is almost a high level language", and is directly executed by hardware plus microcode or millicode (or whatever IBM calls the millicode/PALcode/whatever in the newer processors), with System i, which is ultimately a descendant of the old System/38, and whose "instruction set" (TIMI) is an uber-CISCy instruction set that's not executed directly, it's translated to the "real" native instruction set, which used to be a somewhat 360-ish CISC instruction set (IMPI) and is now an extended form of Power (Power/AS).
The proper solution is to make programmers aware of leap seconds. There are 86400 seconds in a normal day, however there is an additional second added once or twice a year to adjust for solar time. Wikipedia documents it quite well and programmers in modern times should be heading to wikipedia almost constantly anyway. The real problem occurs when the date/time is given in seconds since an "event" such as Jan 1, 1970. Most programmers don't know about leap seconds and I must admit, I don't generally bother calculating for them. But if it were necessary, it would be relatively trivial to do so.
Arthur Olson and company knew about them and even wrote code to calculate for them. A lot of UN*Xes out there use that code (or the glibc code, which, as I remember, was a GPLed reimplementation, reading the same file format).
The untitled version of HR 1586 does have content.
Not any more, it doesn't - clicking on that link gets a complaint that your query has timed out (perhaps not surprising, given the last component of the URL - C?c111:./temp/~c1117DsjMP). However, if you go to the page for HR 1586, you can click on the link for "XXXXXXAct ofXXXX (Engrossed Amendment Senate - EAS)" to see it in HTML, or the PDF link, which has a slightly less temporary-looking URL.
He didn't actually say you can't.
He did, however, say, "No they really don't. It's why you can't run Mac OS on an IBM PC-compatible, without some major hacking.", where "they really don't" refers to "They use the SAME INSTRUCTION SET."
The statement "No, they really don't" is false; they really do run the same instruction set, for all sane definitions of "instruction set". The reasons why "major hacking" is required have nothing to do with the instruction set the processors used in Intel Macs and the processors used in PC-compatible machines support.