Log in

No account? Create an account
In which Rob proves his site-finding l33tness - Baxil [bakh-HEEL'], n. My Sites [Tomorrowlands] [The TTU Wiki] [Photos]
View My LJ [By Tag]

June 4th, 2007
08:41 pm
[User Picture]


Previous Entry Share Next Entry
In which Rob proves his site-finding l33tness

The scene: Our two heroes are at their tech support job, looking up some technical data vaguely relevant to one of their latest support tickets.

baxil: Huh? That's really bizarre. The most recent iMacs support a maximum of 3 gb of RAM.
roaminrob: What? That's a stupid cap. A longint is 4 gb; why not use that? There has to be some arbitrary limitation that has nothing to do with memory addressing.
B: 4 gb or even 2 gb I could understand. Then you at least have paired SO-DIMMs and can get the speed boost. But a maximum of three gb in two slots?
R: Lame. Speaking of which, did you ever buy that RAM upgrade for your Mac Mini?
B: Hmm. (*google*) "The Intel chip set used inside has limited memory addressing capabilities, meaning 3GB is the most the system can address."* And no, I didn't ... I thought about it a few weeks ago at Fry's, but they had two different sets of PC5300s, one of them labeled specifically for Macs, which were of course more expensive ... I haven't done enough research to find a good deal ... (Blah blah, whine whine.)
R: Ah, but while you have been distracted with the 3gb thing, I have found your RAM, labeled specifically for Mac use, at a price modestly lower than your best deal. Et voila, $78.00 per 1GB chip! (*sends link*)
B: ...
R: ...?
B: You read that wrong. That's $78 for the entire 2gb upgrade kit.
B: Where's my credit card? And how the hell did you find this?
R: Dealmac. And damn, does it feel good to have my Internet mojo back.
B: You know, your track record of "recommending sites to me that begin with a D and are TOTALLY AWESOME" is now two for two.
R: You're welcome. It's not just Dealmac - check out their RAM side at DealRAM and their generic computer gear side at DealNews.
B: Seeing as how I am off the clock, I plan to. (*surfs*)
R: (*works*)
B: ... !!!
R: ?
B: Dude. (*frantic gesticulating*)
R: (*walks over*)
R: ... A Marmot Precip for $49?!?!
B: O_O;
R: Wow.
B: Excuse me, I think I just wet myself. (*runs to bathroom*)

Current Location: ~yuba
Current Mood: impressedimpressed
Tags: , ,

(30 comments | Leave a comment)

Date:June 5th, 2007 05:59 am (UTC)
...Dude. What kinda lame assed system are they using that can only address three gigs, and why in god's name did Apple use it?
[User Picture]
Date:June 5th, 2007 06:15 am (UTC)
I would call that lame-assed system a Pentium 4. I'm running 3GB on my desktop and can't expand it any more until I get a new CPU; that's the maximum it's willing to address.

Note that I do not disagree with your summary of lame-assed.

Of course, a few weeks ago, that computer had 1GB of RAM. Then I went to what is apparently the Windows equivalent of the site you linked; Memory Giant gave me another 2GB (in two 1GB sticks- I had 4 slots on my computer, only 2 in use) for $80-ish, with free shipping.

Then I "upgraded" to Vista, making the memory upgrade not only moot as far as improving performance is concerned, but damn near mandatory.
[User Picture]
Date:June 5th, 2007 06:18 am (UTC)

P. S.

I only wish I could get a similar deal on upgrading my Tablet. (No, MemoryGiant and similar sites have no idea what to make of this computer, much less what type of memory it needs, although similar models have leads. Customized model problem, or this particular model using a proprietary memory chip?)
Date:June 5th, 2007 06:40 am (UTC)

Reserved physical addresses for memory-mapped I/O and ROM and such?

[User Picture]
Date:June 5th, 2007 12:28 pm (UTC)
Some cheaper Intel boards have this limitation, so it's not just Apple, but many PC's which use cheaper Intel board chipsets.

But right now I'm really scratching my head over the "longint is 4gb" comment above. No compiler I know of makes the longint variable type that big, most computers don't even have the option to address that much ram :)
[User Picture]
Date:June 5th, 2007 05:51 pm (UTC)
I'll let roaminrob field that one.
[User Picture]
Date:June 5th, 2007 06:39 pm (UTC)
Sort of true. A longint by default -- in most languages and architectures, but not all, so you really shouldn't count on this -- is -2147483648 to 2147483647, because a longint is usually understood to be a 32-bit signed integer.

In memory addressing though, you typically don't use negative addresses, so you get 32 bits of /unsigned/ addressable space, or 0 to 4,294,967,296 = 4 gigs.

Disclaimer: I'd love to be more firm on this and say that this is all universally true, but all this is only based on my experience as a long-time moderately skilled hack. Every time I go and say something absolute about programming, some professional with more experience comes along and says, "No no no, on X platform in Y language it's not that way, so you can't say that!"

Disclaimer disclaimer: But, when I say "in my experience", that includes dozens of languages from 68k and PPC assembly through COBOL to C and its brethren, and more hardware and operating system platforms than I could modestly list. :-)
[User Picture]
Date:June 5th, 2007 07:10 pm (UTC)
Nope. You got this one right.

sizeof(short) = 1
sizeof(int) = 2
sizeof(long) = 4

on almost every architecture I can think of. There are a few more modern scripting languages which allow arbitrary-sized integers and arbitrary precision floating point constructions (like Mathematica), but those are the exception rather than the norm.
Date:June 5th, 2007 09:19 pm (UTC)

The C99 standard says that short, int, long, and long long have to be at least 16, 16, 32, and 64 bits long respectively, if I'm interpreting it right. I'm not sure what C89 says.

The cases I've seen for the sizes of C data types for processors with different-width pointers/machine words go approximately like this:

Machine word:16-bit32-bit64-bit
sizeof(int)244; 8 if ILP
sizeof(long)448; 4 if LLP
sizeof(long long)888

"ILP", "LLP", and "LP" refer to ways of assigning type sizes that make {Integer, Long, and Pointer}, {Long Long (only) and Pointer}, or {Long and Pointer} 64 bits wide, respectively, leaving the others at 32 bits. I've heard x86_64 Windows primarily uses LLP, but my GCC uses LP. Any of those is allowed by the C standard.

Date:June 5th, 2007 09:43 pm (UTC)

Actually, in memory addressing, the address space is commonly visualized as unsigned (and indefinite, if you're just theorizing about memory layouts in general), but in practice is in the Galois field of 2N, where N is the pointer size in bits. This is mostly since integer addition on operands of pointer size usually computes in the Galois field of 2N, and one rarely has occasion to multiply or divide pointers directly. Unsigned is a more convenient way to visualize it, but signed and unsigned come out the same way anyway.

Interestingly enough, in AMD64, you have 64-bit operands, but you don't have a full 64-bit virtual address space; pointers only have 48 significant bits, even though they're encapsulated in 64-bit values. Moreover, the extra 16 bits at the top must be the sign extension of the 48-bit pointer underneath; anything else isn't in "canonical form" and will raise an exception if accessed. That effectively forces the 48-bit pointers to be signed for practical purposes, as the pointer representations don't go all the way around GF(264) and are only contiguous if you treat zero as being in the middle. The result is that (I interpret) there's a strong pressure to make negative/positive into kernel/user pointers; x86_64 Linux does this, for instance. User programs get 47 significant bits of address, always positive, and kernel gets the other 47-bit half in the negative region.

[User Picture]
Date:June 5th, 2007 10:30 pm (UTC)
Oh yes he is talking about the memory address itself, that makes more sense. It was a bit early in the morning and I read it wrong :P
Date:June 5th, 2007 09:34 pm (UTC)

To shorten some of the above comments: basically it's not "long integers are 4 GiB wide" but "pointers the size of long integers have an addressing range of 4 GiB".

[User Picture]
Date:June 5th, 2007 05:40 pm (UTC)
I don't totally understand it - I know a lot more about computers than the average person, but I'm not a programmer - but I was reading a little while ago that 32-bit Windows, at least, is incapable of using more than 3GB in a productive way, unless you have programs specifically designed to understand Physical Address Extension? (As in, the OS can see the RAM, but most programs can't use it on a 32-bit OS.. I think?) I don't quite follow what it's about though, or whether it applies to other operating systems.
Date:June 5th, 2007 09:33 pm (UTC)

There's a difference between physical addresses and virtual address space. In the absence of address translation, you only have physical addresses, but almost all operating systems use address translation nowadays, so the physical addresses are mapped into one or more virtual address spaces. How much memory can be directly addressed at one time is limited by the pointer size; on a 32-bit processor, pointers are 32 bits. When you're using translation, though, it's possible to have page table formats that include more than 32 bits of physical address, even though you only get 32 bits of virtual address; then you can access the different parts of physical memory from different virtual address spaces. Most modern 32-bit Intel processors, for instance, have "PAE", "Physical Address Extension", which gives you another four bits of physical address in the page tables, letting you map 64 GiB of physical address space.

Now, virtual address space is usually constrained for reasons of performance and convenience to have some of it reserved by the kernel. In 32-bit address spaces, usually the top 1 GiB or 2 GiB will be reserved, leaving only 3 GiB or 2 GiB of usable address space for each user process, rather than the full 4 GiB. That might have been the source of that statement. A user program wouldn't be capable of using PAE directly, as it would be meaningless—the operating system can (and generally will, when memory is full enough) map pages from higher areas of RAM into the program's address space, but the program itself can still only directly address its 2 GiB of 3 GiB without explicitly juggling memory maps (which it could do anyway in a system with disk-based virtual memory, even without PAE). (I don't know how the equivalent of mmap works on Windows, so I'm semi-guessing regarding the explicit juggling.) A program that splits its execution up into multiple processes, each of which would have its own virtual address space, might be able to be somewhat more effective. That applies to most multitasking operating systems that use one address space per process.

[User Picture]
Date:June 5th, 2007 10:12 pm (UTC)
In other words:

Program says, "I needs a memory!"
Windows says, "You gets a address!"
Program says, "I want allzor memory!"
Windows says, "U can has all my memory, except for the first few bits of every address, because I do speshul things there."

A less brain-dead memory manager wouldn't need to gobble up a few bits of every address. My best guess would be that Windows is setting some flags in there, i.e., if the most significant address bit is set (is "1"), then the address is a relocatable block. (Except Windows doesn't have relocatable blocks that I know of, but this was just a random example. MacOS used to do something like this to their addresses before OS X.)
Tomorrowlands Powered by LiveJournal.com