On Aug 16, 2012, at 4:37 AM, Vincent Habchi <vi...@macports.org> wrote:
> On 16 août 2012, at 03:11, Britt Durbrow > <bdurb...@rattlesnakehillsoftworks.com> wrote: > >> objects must be 16-byte aligned - and that alignment requirement isn't >> likely to go down, but rather up in the future; using the low bits doesn't >> really cause the same issue that using the high bits did. > > Well, I partly disagree. There is no real difference in using MSB or LSB. At > some point in the future, Intel can decide to use low bits to serve some > specific hardware purpose, like signaling uncachable addresses on a fine > granularity, indicating what core had fetched the pointer, or deciding at > fetch time what kind of info is being accessed and route the incoming data > accordingly, and so on. > Well, they *could*, but I don't think they *will*. Doing that would cause so many problems that I think it's totally unfeasible: 1) At the hardware level, pointers are just unsigned integers. The same instruction used to fetch an integer is used to fetch a pointer. 2) Pointer arithmetic would be totally messed up. Code that did pointer arithmetic as unsigned integers would break (yes, I know it's outside of the spec for many languages, C included, but a lot of software already out there does this, even though it's not really supposed to. It isn't outside the spec for assembler though, and there's a lot of assembler out there too). 3) Due to 1 and 2, they would have to introduce a set of new instructions that just do pointer handling on large objects. 4) You wouldn't be able to use the same kind of pointer to reference small objects (char, short, etc) as large objects (i.e, stuff with the 16-byte alignment requirement). Also, conversion from one type to the other would be impossible without loosing data. 5) Backwards compatibility - both binary and source level - would be totally broken... a *major* consideration for Intel. 6) The runtime would have to mask off the low bits of the address anyway in order to follow the isa pointer - if Intel did as you suggest they might; the runtime could handle this by treating the pointer as a purely computed address; not a fetched one. 7) And other stuff that I'm sure I'm missing at the moment. The same considerations also apply to any existing architecture (i.e, ARM, etc) that would do that; and most of them would apply to any potential new architecture. >> Oh, and it bit the Mac too - anybody remember the Mode32 extension from the >> System 7 era? > > At that time I wasn’t developing on Mac, which was far too expensive for the > means of a poor student. But I clearly remember having written the equivalent > for the Atari TT/Falcon, MMUPATCH.BIN, a short TSR assembly code that would > tinker with the MMU of the 68030 to redirect all logical addresses XXYYYYYY > towards physical addresses 00YYYYYY. That was a clear kludge, but it > prevented some occasional bombing ;) > > Vincent > > As I recall (heh, it's been a while! :-) the Mac Toolbox ROM's Memory Manager used to stuff metadata about handles (relocatable pointers-to-pointers) in the high bits of an address; and what Mode32 did was to patch the trap table to use the newer 32-bit clean Memory Manager routines on machines that had the older ROM installed (I don't *think* it patched out the whole ROM, but I could be mistaken... as I said, it's been a while). > > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/bdurbrow%40rattlesnakehillsoftworks.com > > This email sent to bdurb...@rattlesnakehillsoftworks.com _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
