Talk:Intel Memory Model
It should be noted that most of this article doesn't refer to the "C memory model," but rather the Intel segmented memory model as implemented in C compilers for the x86 architecture. --Joe Sewell (talk) 18:28, 7 January 2009 (UTC)
- Yes, and a generalization needs to talk about the C memory model in the development of Unix - they would refer to IP16 with "int" and "pointer" as 16bit (and "long" as 32bit) up to the now common LP64 where "long" and "pointer" are 64bit (and "int" 32bit) while most platforms were ILP32 where it has some problems to port the software to other platforms just because everything was the same. These epressions are common idiom when talking about the memory model assumed by the C compiler. The DOS pointer model is merily a side issue. Guidod (talk) 09:41, 12 September 2009 (UTC)
Mfwitten (talk) seems to have partly taken care of this in revision of 14:32, 18 February 2010: the article is now called Intel Memory Model. Now all that's needed is a more general article at C memory model; right now it just redirects to here. --SamB (talk) 19:05, 20 August 2010 (UTC)
number of preallocate segments
I can vaguely remember some memory model having only one ds for static data (saving a ds load for all static data), and the one above it only guaranteeing that a compilation unit has the same ds always.
Does sb remember details about number of datasegments for static data?
(same author remembering more on rereading this) The compiler was the TopSpeed 3.x series. IIRC the one static datasegment memory model was called "large", the multiple static datasegment was called xlarge.
No "huge" pointer normalization and >16-bit address calculation was performed (at least not in the real mode models, I didn't have the extender, which was a separate sell)
Both models required ds to be preserved, I'm less sure about es, iirc large required es to be preserved and xlarge not.
The Large model was quite close to what Turbo Pascal (in real mode) did.
In XLarge iirc the ds was supposed to point to the local compilation unit's ds when calling a non-exported (local) function, so not exported functions essentially had a "large" model and could assume ds to point to their variables. TP had no equivalent for this.
Exported functions had to preserve ds and reload it with their own segment.
I removed the following sentence: "In protected mode, the GDT and LDT are used for this purpose." It doesn't really provide any useful information or say what "this purpose" is. Instead I indicated in the lead that this article describes operations in real mode. Peter Flass (talk) 14:00, 22 February 2014 (UTC)