On 9/2/2013 6:11 PM, Joel Rees wrote: > On Mon, Sep 2, 2013 at 4:41 PM, Stan Hoeppner <s...@hardwarefreak.com> wrote: >> On 9/1/2013 9:44 PM, Joel Rees wrote: >>> On Mon, Sep 2, 2013 at 7:18 AM, Pascal Hambourg <pas...@plouf.fr.eu.org> >>> wrote: >>>> Richard Owlett a écrit : >>>>> Stan Hoeppner wrote: >>>>>> >>>>>> So I fail to see why your knowing the "CPU bus width" is relevant to >>>>>> anything. >>>>> >>>>> If I understand correctly some processors can run 32 bit OSes but >>>>> not any 64 bit OS. >>>> >>>> This has nothing to do with bus width. >>> >>> Not an entirely separate issue from the address bus width, however. >> >> While it's possible to back track a CPU's ISA from knowing the address >> line width, there are far more practical and fool proof methods to >> determining the ISA. > > Really? I mean, for the un-initiate?
The un-initiate isn't going to care. >>> Just for fun, I looked at what this box tells me with lscpu and >>> cat-ting /proc/cpuinfo. The relevant lines in the reply are, for >>> lscpu, >>> >>> CPU op-mode(s): 32-bit >>> >>> which tells me that it can run OSses in 32-bit mode, I think. >> >> You're making this harder than need be. Look at the 'flags' data in >> /proc/cpuinfo. If you see 'lm' it's a 64 bit ISA CPU and can run a 64 >> bit OS. If 'lm' is not present it's a 32 bit only CPU. 'lm' represents >> "Long Mode" which is the operating mode of x86-64 processors that >> enables execution of 64 bit instructions. > > Which is great if you happen to know that lm iin the flags means "long > mode" You know now. > and that "long" in this case means the ability to use and > calculate "long=64 bit" addresses at a pace useful enough to run the You seem to be intentionally taking a single word out of context to build an invalid argument below. It's "long mode", and yes, context matters, always. > 64 bit (addressing) OS. And note there is no such thing as "64 bit addressing". There has not been, nor will there be in the near future, a 64 bit CPU that has 64 bits of either physical or virtual address space. CPUs with 46 bit physical and 48 bit virtual addressing exist today, yielding 64TB physical and 256TB virtual address spaces. 64 bits yields a 16 exabyte address space. 50 bits is 1 petabyte, and it will likely be many years before we see CPUs with 50 bits of physical or virtual addressing. SGI is the only vendor that could make use of a 50 bit address space. But it doesn't appear to they plan to offer the 4096 socket 64 cabinet machine required to hold 1PB of DRAM. Interestingly enough they did build a translation mechanism into the NUMALink 5 router ASIC to support a 50 bit physical address space regardless of the Xeon CPU limitations. They've been "stuck" at 256 sockets for two generations of Altix UV. I guess it's good to have the capability in the event the US Govt asks for a 4096 socket machine out of the blue. NSA may have already purchased one and we'd never know. And NSA has the prime workload, pattern matching of very large datasets, that require massive main memory. > (And it's not just us old fogies. There are still a lot of contexts in > which "long" still means 32 bit addresses. I'm sorry, but "long" != "long mode", no matter your old fogie status. > Just because Intel is > trying to forget its roots doesn't mean the rest of the world is on > their bandwagon.) AMD, not Intel, invented the x86-64® architecture (now AMD64®) of which long mode is a component. Intel reverse engineered and copied it a few years later, and calls it Intel 64®. Your venom is misplaced. -- Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52256569.5080...@hardwarefreak.com
