Jump to content

Talk:x86 memory models

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
(Redirected from Talk:Intel Memory Model)

Intel bias

[edit]

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)[reply]

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)[reply]

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)[reply]

number of preallocate segments

[edit]

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?

88.159.71.34 (talk) 21:14, 17 March 2013 (UTC)[reply]

(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.

Some often called RTL functions had an "exported" stub that reloaded ds and called the local function. 88.159.69.126 (talk) 12:37, 13 September 2015 (UTC)[reply]

Protected mode

[edit]

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)[reply]

[edit]

Hello fellow Wikipedians,

I have just modified one external link on Intel Memory Model. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 15:18, 14 November 2017 (UTC)[reply]

48 bits

[edit]

In the discussion, there is mention of using segments in 32 bit mode, allowing for 48 bit pointers. As well as I know it, the Watcom_C/C++ compiler allows them, and can generate code for them, and maybe a version of OS/2 can execute them. I don't know of a reference, though. It should be in the manuals. Gah4 (talk) 10:12, 10 January 2018 (UTC)[reply]

You are thinking of a 32-bit program which is covered as "other" in this article. The 32-bit "flat" model is the same as 16-bit "tiny" in that code and data have near* pointers. The 32-bit near* pointers are of course 32-bit and the 32-bit far* pointers are 48-bit. Guidod (talk) 19:48, 10 January 2018 (UTC)[reply]
It is possible to use segmentation in 32-bit protected mode as well (resulting in 48-bit pointers) and there exist C language compilers which support that.[citation needed] When I used Watcom-C with OS/2, it could do that. I don't know if it still does. It is the [citation needed] that I was thinking about. Gah4 (talk) 20:10, 10 January 2018 (UTC)[reply]
OK, found it:[1] Gah4 (talk) 20:28, 10 January 2018 (UTC)[reply]

References

  1. ^ "Open Watcom C Language Reference version 2" (PDF). github.com/open-watcom. Open Watcom. Retrieved 10 January 2018.

Requested move 22 March 2022

[edit]
The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this discussion.

The result of the move request was: moved. Uncontested move request. (non-admin closure) Colonestarrice (talk) 08:18, 9 April 2022 (UTC)[reply]


Intel Memory ModelX86 memory models

  1. the subject of the article is six models, not one;
  2. the capitalization is odd: in the article text, memory model is never capitalized;
  3. there exist(ed) non-x86 Intel CPUs (8080, i860, Itanium etc) and they don't use the described models, so the article name better be more specific.

-- 82.166.199.42 (talk) 07:09, 22 March 2022 (UTC)— Relisting. Turnagra (talk) 19:39, 8 April 2022 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.