The software can also handle 32-bit addressing: it just promotes the 32-bit value from the 32-bit-oriented client process to a 64-bit value internally when it needs to get at a real (64-bit) memory address for mapping purposes. The kernel handles this all internally.
More like the other way around - the kernel is 32-bit, but can run userland 64-bit apps.
The only potential problem is that the 'long' datatype is 64-bit on a G5, since OS X uses the LP64 model (Longs & Pointers are 64-bit).
...and that pointers don't fit into an int; the language hasn't guaranteed that they do for a long time now, but that doesn't completely prevent people from writing code, either intentionally or accidentally, that requires that they do.
That's not the speed of light in imperial standards. What is it?
The speed of light in furlongs/fortnight, as calculated by that handy app that comes bundled with OS X, "units":
$ units 500 units, 54 prefixes You have: c You want: m/sec * 2.9979246e+08 / 3.335641e-09 You have: c You want: furlongs/fortnight * 1.8026175e+12 / 5.5474886e-13
These chips are based on a heavily modified version of the P3, which was based on the Pentium Pro. I believe they're a bit more "traditional" CISC-type processors.
Nope. The Pentium Pro had the micro-op stuff, as do its descendants.
That's pretty much the way CISC has been implemented since the IBM 360.
No. The original S/360's did not decode S/360 instructions into RISCy "micro-ops" and execute the micro-ops. S/360's up to the Model 65 had micro-engines that interpreted S/360 instructions, with some amount of hardware assist (i.e., I think the larger ones, at least, at least, had hardware that did at least some of the decoding, with the execution done by microcode). The Model 75 was hardwired. What's done in Intel and AMD x86 chips is that the decoder translates the instructions into micro-ops and the hardware executes the micro-ops (with some microcode used).
(I think current z/Architecture chips are also largely hardwired, although they have some sort of millicode/PALcode/etc. equivalent as microcode replacement.)
"and that said... CISC processors sucked until they switched to them."
None of Intel's desktop, notebook or server cpu's are CISC. They haven't been for several years, now. They are actually RISC-like in nature, with a big fat CISC decoder that transforms those nasty CISC commands into "micro-ops."
In other words, CISC processors, i.e. the implementations of CISC instruction sets, may have sucked, but the instruction sets themselves sucked less than people thought.
so was I right that if you define a Uint64 (not sure what the non-sdl name for that is) on a sparc v9 or sgi64 or mmx, it uses 64 bit math in a 32bit object file, and does it use 64 bit reg's mem-cpy's (wait is memcpy a kernel or libc function) on those platforms.
I don't know - I don't have any of those machines handy.
If you compile something as "pure" 32-bit code, it presumably doesn't use 64-bit registers, as "pure" 32-bit code is supposed to run on 32-bit processors that don't have 64-bit registers.
Some 64-bit systems might support what one might call "mixed" 32-bit/64-bit code, which allows all 64 bits of registers to be used but has 32-bit pointers. In "systems" I include the OSes and the compilers - the OS (kernel and/or user libraries) would have to support 32-bit pointer types but still allow all 64 bits of registers to be used.
Where did it say "no one uses software emulation" in the article? They were saying nobody was using the hardware emulation of x86 in the Itaniums, so they were going to remove it from the next Itanium 2 and use just, err, umm, software emulation.
and that 64 bit address pointers introduce a performance penalty (not sure why).
You've guessed at least part of it:
but use 32 bit address pointers, so as to use less memory
Data structures with 32-bit pointers are smaller than those with 64-bit pointers, so the data structure takes less of a chunk out of your cache (hopefully reducing the number of cache misses, where you have to fetch stuff from slower main memory) and less of a chunk out of your main memory (hopefully reducing the number of page faults, where you have to fetch stuff from an even slower disk or file server).
They ported every release to PPC. Yes off course it needed aftercare, but still: first for n86, then to PPC.
And the evidence you have to support the claim that the development cycle involved getting stuff running on x86 first, and then when that was done getting it running on PPC, is? (Note that most changes to OS X between releases don't involve "porting" the changes; most of them would Just Work.)
This doesn't say that releases weren't also made to run on x86 - Jobs said as much - but I've seen no indication that the primary development target was x86.
so why the focus on getting the bare binary to run under Rosetta, rather than the.app bundle?
Because some software for OS X might not have all its executables as apps run from.app bundle. It might include daemons, or it might include command-line apps.
(One of the apps I'm involved with has a command-line app and an X11-based GUI app, and has, in the past, had code contributed to it that broke when run on big-endian machines. Being able to test both the big-endian and little-endian versions on a MacIntel would be useful. That might be useful for some commercial apps, too.)
I'm not sure I understand the distinction you're making...
The distinction between making an arbitrary fat Mach-O executable run under Rosetta when you invoke it from the command line and between making a fat Mach-O executable inside an application bundle run under Rosetta when you, for example, double-click on the app.
perhaps the Forcing an Application to Run Translated section of Apple's Universal Binary Programming Guidelines has the answer to your question though.
Ultimately, yes.
"Make a Setting in the Info Window" didn't apply - there was no such setting in the Info window for the binary in question.
"Modify the Property List" didn't apply because it's an executable image, not an application bundle, and has no Info.plist file.
"Use Terminal" does, in a sense, but it achieves the goal by sending the executable to the fat farm - the ditto command in question forces it to run under Rosetta by making a PPC-only copy; the PPC-only copy runs under Rosetta on x86 because it has to. It handles the "compile it... for PPC only" part of my question, but not the "compile it fat" portion.
"Use sysctlbyname" does; I whipped up a small program with that sysctl that should run an arbitrary fat executable under Rosetta on x86.
The easiest way to run a fat binary under Rosetta is to open the Get Info panel on it and check the "Open using Rosetta" checkbox.
You meant to say "the easiest way to run a fat application...", with "application" meaning "item delivered in the form of an application bundle". There ain't no such check box on a fat binary, just on the top-level ".app" directory under which the binary (and other stuff) is stored.
They can compile for all architectures from either a PPC or x86 Mac.
But they can test for all architectures only on an x86 Mac, as there's no flavor of Rosetta to run x86 binaries on PPC machines - and it's not possible to run all x86 code in Rosetta; no kernel loadable modules (kexts), and I think some userland plugin modules might not also work; I don't know whether you can force arbitrary fat binaries to run under Rosetta ("arbitrary" means "if I download the source to GNU Hello and compile it fat or for PPC only, can I run the resulting executable image under Rosetta?", not "can I tell Launch Services or whatever does this to launch an arbitrary.app under Rosetta?").
Intel's AMD64 instruction set is SLOWER than their IA32 instruction set.
Really? A 64-bit Pentium D is slower than a 386SX?
Oh, what you meant was "Intel's current chips that implement AMD64 run slower in 64-bit mode than in 32-bit mode". That doesn't necessarily mean future implementations will be slower in 64-bit mode. The chips using the "Next Generation Microarchitecture" might not have that problem.
(Well, technically, that might be "implement EM64T". The Wikipedia article on EM64T, at least, claims there are some differences, although, if it's correct, some of them went away in newer chips, and others are just standard AMD vs. Intel differences, e.g. the lack of 3DNow! instructions in EM64T.)
The NetApp FAS900 filers, and most earlier NetApp x86 machines, use Open Firmware (the exceptions were the machines, mostly NetCache machines, using standard Intel boxes OEM'ed). Now, that was a port of the Firmworks OpenFirmware code to x86, rather than a version of Apple's independently-implemented Open Firmware implementation, but there's nothing technical that prevents Open Firmware from running on x86.
I thought it was "Do not meddle in the affairs of wizards, for it makes them soggy and hard to light."
Re:You forgot one...Flash memory based ibook!
on
The Odds at Macworld
·
· Score: 1
Why else would apple be going around buying all the flash memory and securing deals for several years out?
Yeah, it's not as if Apple currently have any hot selling products with flash memory, and might expect to be selling a lot of them for the next several years, after all....
That means the "UNIX/Linux" category is at least 10 OSes.
...or more, if you count different Linux distributions as different OSes (see another comment of mine for an example of how multiple distributions could be inflating the "Unix/Linux" numbers).
The careful reader will note that one problem is that both "tcp dump"[sic] and "TCPDump"[sic] have a "BGP Decoding Routines Denial of Service". Of course, WinDump isn't listed there, even though it has the same decoder, although, as it doesn't come with Windows, perhaps it isn't counted as a Windows vulnerability.
It would also be worth checking to see whether, as noted, any of the updates really deserve to be treated as separate vulnerabilities (regardless of whether they're UN*X vulnerabilities or Windows vulnerabilities). As far as I can tell, the updates for the tcpdump BGP decoding DOS just either say "oh, this OS also has it" or "oh, this OS also has a fix" - there are a small number of those you can get for Windows, but a larger number for "Unix/Linux" vulnerabilities, given that there several major Linux distributions, four major BSD/386 descendants, and several "commercial UNIXes".
$ otool -L/Applications/iTunes.app/Contents/MacOS/iTunes /A pplications/iTunes.app/Contents/MacOS/iTunes: /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.2) /System/Library/Frameworks/Carbon.framework/Versio ns/A/Carbon (compatibility version 2.0.0, current version 128.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.0.81) /System/Library/Frameworks/IOKit.framework/Version s/A/IOKit (compatibility version 1.0.0, current version 271.0.81) /System/Library/Frameworks/QuickTime.framework/Ver sions/A/QuickTime (compatibility version 1.0.0, current version 47.0.0) /System/Library/Frameworks/vecLib.framework/Versio ns/A/vecLib (compatibility version 1.0.0, current version 182.0.0) /System/Library/Frameworks/AGL.framework/Versions/ A/AGL (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/OpenGL.framework/Versio ns/A/OpenGL (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/CoreAudio.framework/Ver sions/A/CoreAudio (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/AudioUnit.framework/Ver sions/A/AudioUnit (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/CoreServices.framework/ Versions/A/CoreServices (compatibility version 1.0.0, current version 18.0.0) /System/Library/Frameworks/SystemConfiguration.fra mework/Versions/A/SystemConfiguration (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/Security.framework/Vers ions/A/Security (compatibility version 1.0.0, current version 222.0.0) /System/Library/Frameworks/AudioToolbox.framework/ Versions/A/AudioToolbox (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/AddressBook.framework/V ersions/A/AddressBook (compatibility version 1.0.0, current version 472.0.0)
(note more the lack of Cocoa than the presence of Carbon - otool -L on Safari reports both Cocoa and Carbon).
X11 clients and servers run on Linux, UNIX, Windows, OS X, and dozens of other operating systems.
Linux, "UNIX", and at least some of the other OSes (if they're not grouped under "UNIX") really only count as variants of one flavor of OS; they're all "UNIX-compatible" (classic Mac OS, VMS, etc. count as "other" in this context, but Solaris, various BSDs, HP-UX, AIX, Digital UNIX, IRIX, etc. don't). One could give OS X a little more credit, as its native window system isn't based on X11, so the server side is a bit more interesting, but on the client side it's just another variant of "UNIX-compatible".
Slashdot Mirror
More like the other way around - the kernel is 32-bit, but can run userland 64-bit apps.
...and that pointers don't fit into an int; the language hasn't guaranteed that they do for a long time now, but that doesn't completely prevent people from writing code, either intentionally or accidentally, that requires that they do.
The speed of light in furlongs/fortnight, as calculated by that handy app that comes bundled with OS X, "units":
Nope. The Pentium Pro had the micro-op stuff, as do its descendants.
No. The original S/360's did not decode S/360 instructions into RISCy "micro-ops" and execute the micro-ops. S/360's up to the Model 65 had micro-engines that interpreted S/360 instructions, with some amount of hardware assist (i.e., I think the larger ones, at least, at least, had hardware that did at least some of the decoding, with the execution done by microcode). The Model 75 was hardwired. What's done in Intel and AMD x86 chips is that the decoder translates the instructions into micro-ops and the hardware executes the micro-ops (with some microcode used).
(I think current z/Architecture chips are also largely hardwired, although they have some sort of millicode/PALcode/etc. equivalent as microcode replacement.)
In other words, CISC processors, i.e. the implementations of CISC instruction sets, may have sucked, but the instruction sets themselves sucked less than people thought.
I don't know - I don't have any of those machines handy.
If you compile something as "pure" 32-bit code, it presumably doesn't use 64-bit registers, as "pure" 32-bit code is supposed to run on 32-bit processors that don't have 64-bit registers.
Some 64-bit systems might support what one might call "mixed" 32-bit/64-bit code, which allows all 64 bits of registers to be used but has 32-bit pointers. In "systems" I include the OSes and the compilers - the OS (kernel and/or user libraries) would have to support 32-bit pointer types but still allow all 64 bits of registers to be used.
Where did it say "no one uses software emulation" in the article? They were saying nobody was using the hardware emulation of x86 in the Itaniums, so they were going to remove it from the next Itanium 2 and use just, err, umm, software emulation.
So did Intel, after AMD did.
You've guessed at least part of it:
Data structures with 32-bit pointers are smaller than those with 64-bit pointers, so the data structure takes less of a chunk out of your cache (hopefully reducing the number of cache misses, where you have to fetch stuff from slower main memory) and less of a chunk out of your main memory (hopefully reducing the number of page faults, where you have to fetch stuff from an even slower disk or file server).
And the evidence you have to support the claim that the development cycle involved getting stuff running on x86 first, and then when that was done getting it running on PPC, is? (Note that most changes to OS X between releases don't involve "porting" the changes; most of them would Just Work.)
This doesn't say that releases weren't also made to run on x86 - Jobs said as much - but I've seen no indication that the primary development target was x86.
Because some software for OS X might not have all its executables as apps run from .app bundle. It might include daemons, or it might include command-line apps.
(One of the apps I'm involved with has a command-line app and an X11-based GUI app, and has, in the past, had code contributed to it that broke when run on big-endian machines. Being able to test both the big-endian and little-endian versions on a MacIntel would be useful. That might be useful for some commercial apps, too.)
The distinction between making an arbitrary fat Mach-O executable run under Rosetta when you invoke it from the command line and between making a fat Mach-O executable inside an application bundle run under Rosetta when you, for example, double-click on the app.
Ultimately, yes.
"Make a Setting in the Info Window" didn't apply - there was no such setting in the Info window for the binary in question.
"Modify the Property List" didn't apply because it's an executable image, not an application bundle, and has no Info.plist file.
"Use Terminal" does, in a sense, but it achieves the goal by sending the executable to the fat farm - the ditto command in question forces it to run under Rosetta by making a PPC-only copy; the PPC-only copy runs under Rosetta on x86 because it has to. It handles the "compile it ... for PPC only" part of my question, but not the "compile it fat" portion.
"Use sysctlbyname" does; I whipped up a small program with that sysctl that should run an arbitrary fat executable under Rosetta on x86.
You meant to say "the easiest way to run a fat application...", with "application" meaning "item delivered in the form of an application bundle". There ain't no such check box on a fat binary, just on the top-level ".app" directory under which the binary (and other stuff) is stored.
Ow. That should be "...all PowerPC code..." (and, yes, I previewed, I just didn't read it carefully enough).
But they can test for all architectures only on an x86 Mac, as there's no flavor of Rosetta to run x86 binaries on PPC machines - and it's not possible to run all x86 code in Rosetta; no kernel loadable modules (kexts), and I think some userland plugin modules might not also work; I don't know whether you can force arbitrary fat binaries to run under Rosetta ("arbitrary" means "if I download the source to GNU Hello and compile it fat or for PPC only, can I run the resulting executable image under Rosetta?", not "can I tell Launch Services or whatever does this to launch an arbitrary .app under Rosetta?").
Really? A 64-bit Pentium D is slower than a 386SX?
Oh, what you meant was "Intel's current chips that implement AMD64 run slower in 64-bit mode than in 32-bit mode". That doesn't necessarily mean future implementations will be slower in 64-bit mode. The chips using the "Next Generation Microarchitecture" might not have that problem.
(Well, technically, that might be "implement EM64T". The Wikipedia article on EM64T, at least, claims there are some differences, although, if it's correct, some of them went away in newer chips, and others are just standard AMD vs. Intel differences, e.g. the lack of 3DNow! instructions in EM64T.)
The NetApp FAS900 filers, and most earlier NetApp x86 machines, use Open Firmware (the exceptions were the machines, mostly NetCache machines, using standard Intel boxes OEM'ed). Now, that was a port of the Firmworks OpenFirmware code to x86, rather than a version of Apple's independently-implemented Open Firmware implementation, but there's nothing technical that prevents Open Firmware from running on x86.
Imagine different. They use EFI.
I thought it was "Do not meddle in the affairs of wizards, for it makes them soggy and hard to light."
Yeah, it's not as if Apple currently have any hot selling products with flash memory, and might expect to be selling a lot of them for the next several years, after all....
...or more, if you count different Linux distributions as different OSes (see another comment of mine for an example of how multiple distributions could be inflating the "Unix/Linux" numbers).
The careful reader will note that one problem is that both "tcp dump"[sic] and "TCPDump"[sic] have a "BGP Decoding Routines Denial of Service". Of course, WinDump isn't listed there, even though it has the same decoder, although, as it doesn't come with Windows, perhaps it isn't counted as a Windows vulnerability.
It would also be worth checking to see whether, as noted, any of the updates really deserve to be treated as separate vulnerabilities (regardless of whether they're UN*X vulnerabilities or Windows vulnerabilities). As far as I can tell, the updates for the tcpdump BGP decoding DOS just either say "oh, this OS also has it" or "oh, this OS also has a fix" - there are a small number of those you can get for Windows, but a larger number for "Unix/Linux" vulnerabilities, given that there several major Linux distributions, four major BSD/386 descendants, and several "commercial UNIXes".
Carbon:
(note more the lack of Cocoa than the presence of Carbon - otool -L on Safari reports both Cocoa and Carbon).
I'll believe it, Arthur, when Mind.Forth gets an FP here.
I.e., one where the people who talk at meetings make it possible to play Bullshit Bingo?
Linux, "UNIX", and at least some of the other OSes (if they're not grouped under "UNIX") really only count as variants of one flavor of OS; they're all "UNIX-compatible" (classic Mac OS, VMS, etc. count as "other" in this context, but Solaris, various BSDs, HP-UX, AIX, Digital UNIX, IRIX, etc. don't). One could give OS X a little more credit, as its native window system isn't based on X11, so the server side is a bit more interesting, but on the client side it's just another variant of "UNIX-compatible".