segment size in IA32e, what is limit register?

segment size in IA32e, what is limit register?

I understand there is a nice flat mode in IA32e mode that can address 64 bits for offset and base of seg reg, but that's I (?) guess only for LDTR GDTR IDTR or is it for all the seg regs too? I thought all the seg regs were 16-bit?

what does the limit register do, what is it, how many bits is it, how does it fit into the addressing  scheme exactly, how is it loaded (through special instructions?), and where do I find documentation on it that describes what it's for and how it works? I tried looking through the docs, but did not find, maybe I just got lost.


at least with this info, if it's the compiler's fault, I can help the folks fix the compiler.


I am running into compiler segmentation faults because my functions are too big (with a 64-bit target, 64-bit host compiler??? you have got to be kidding) I am guessing it's the old 64k limitations we used to have with 8088. are we still having the same issues with today's 64-bit procs? what happens when we go to 128-bit or 256-bit? I already need 128-bit ints (128-bit native registers) in a standard desktop processor in order to process SI and IEC units without mangling them.


I am making a formal request to fix the small limitations of the 64-bit proc. my function was only 1000 lines of C++, but was full of if's and strings on every line (it was a formatted output generator based on format strings). I think I can reduce my code here, but there is another program I have where I cannot reduce my code, and it has a huge main() with the same problem, and it cannot be modularized to my knowledge and I can't continue to write my embedded database application with things the way they are now.

please fix with new CPU designs or microcode changes. thanks. I wouldn't even mind if 128 bits were loaded from memory 64 bits at a time just as long as I had the functionality.

I would like to see at least 128-bit registers and 256-bit registers instead of 64-bit internals. it can keep the existing bus size. I would like to see the cpu's floating point double and quadruple in size as well.

the time computing tasks I am doing are seeing problems with even 64-bit numbers and need at least 128-bit numbers. SI and IEC units need at least 128-bit numbers. (need at least 90 bits for a multiply just for the year 2017)

9 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

I don't understand what you're asking. Please provide an example program and a log of how you compiled it and whatever error you get at runtime. You refer to "segmentation fault" - that's a Linux/OS X/UNIX term where on Windows (this forum is for Windows) the message would be "access violation".

If I read between the lines of your post, you got a "segmentation violation" and got derailed into discussions of processor registers. This message simply means that you tried to access data at an invalid address, which is almost always caused by a programming error.

Please show us a test case and a log of running the program and we can help further.

Retired 12/31/2016

it might be too much reading, 10k lines of unfinished C++  code and it's in one file (it could get larger too), mostly in one function. embedded database.

I still have questions about the cpu architecture that are not answered yet (see the oritinal post).

sounds like it's a gcc compiler bug, then I need to address that. but I want to be sure. I need the info on the IA32 cpu architecture (for example, the i7-3970x) in order to understand how things are working under the hood - I need to know exactly what limitations the cpu imposes on designing software. most programmers code their C code in small C or C++ functions. mine can be pretty big, with 1/2 code and strings.

this is a 2 parts post. I am also making a request for more bits in integer and floating point registers in the cpus. it doesn't necessarily have to be a wider bus (for instance, the 8088 had an 8-bit bus and 16-bit registers and instructions). I am asking for 128-bit and 256-bit integer and floating point registers (in fact, some fixed point would be a nice feature too).

thanks for the tip on the segfault. so then it's similar to windows' 0xc0000005 Access Violation. I will notify the compiler folks. it's gcc.

I still need to know about the cpu architecture. please answer the questions posted in the original post. I need this information about the cpu's design so I know how to write my code. IF there are certain limitations, I need to know about them, where they are and what they are.

and I still need an upgrade to the existing CPUs. they just don't have enough bits in the registers to handle the kinds of math I am doing.

my problem is, I can't even compile my programs or run my scripts because of the limitations I am running into right now.  one program I was able to reduce in size yesterday. but I am pretty sure the time stuff I can't and unsure about the embedded database stuff. one of the applications is intended to be both a web and a desktop application for calculating time. I would be unable to with the others (one is a web application that won't work with multiply because the number is 63682070400000 so 63682070400000*63682070400000 comes out to about a little over 2^90 bits which is greater than 64 bits and floating point is breaking this application, I need to use integers). I am working with julian-to-gregorian conversions, SI and IEC units.

If needed, view the source of time-funcs.js GregorianToJulianDTime() or JulianDTimeToGregorian() at

SI units go up to 10^24 and equivalent IEC to 2^80. current cpu architecture only goes to 64 bits. that's less than 80. 128 would fit the bill as a minimum. I work with those a lot, and am quite limited by current cpu architecture and lack of BigInt in c++ compilers and other languages. I think if the CPUs get more bits, languages will follow.



Downloadtext/x-c++src guibackend.cpp685.89 KB

Just to get my head around this correctly:

1) You are asking about C++ code being compiled with gcc

2) When you say "IA32" you mean "intel64"

3) You primary concern is the architecture underlying modern intel CPUs

4) This has nothing to do with Fortran or Windows.

For architecture needs, see the intel manuals here: which detail the instruction set, but not necesarily what is going on in the silicon.  

For your large integer needs in c++, I suggest familiarizing yourself with the 3rd party Boost library and in particular this:

For your hardware concenrs, take note that the intel represantitives you'll encounter in this forum are involved with fortran compilers and not the guys who are designing the hardware.

There's lots of good gcc and g++ documentation for both 32- and 64-bit mode on Intel platforms.  The gcc-help mailing list is a good place to answer questions, once you've made an effort to study the available resources.  On linux and MacOS, Intel icpc is based on g++ compatibility, so many of the answers would be the same, and the Intel C++ forum would be relevant.  For Windows, Intel software tools are relatively weak on g++ compatibility, since Microsoft C++ is used as the basic library, include file, and linker support.  Intel Amplifier profiler for Windows recently added g++ profiling facility, in case you might be interested.

You need to make up your mind which language and OS, and g++ implementation you are interested in and study the normal facilities before going off an a tangent about low level aspects.  You can't expect Intel forums (certainly not the Fortran ones) to deal with your ideas for retargeting gcc/g++.

In Fortran for Windows, which is the subject of this forum, the only good way to access an address space > 2GB is by allocatable arrays.  As you seem to be guessing, the address space might be considered segmented, in that Windows resembles the mc_model=small model of x86-64 where the program and static data space is limited to 2GB.

The C equivalent of Fortran allocatable, roughly speaking, is malloc(), and C++ has both new[] and a different flavor of malloc(), which can give you large flat address spaces, up to the physical limit of the CPU of your choice, which may be something between 40 and 48 bit address (certainly not approaching 64 bits).

this does have to do with windows. that's my platform. I have been trying to go through the arch manuals. that's how I ended up with these questions. they didn't seem to answer some of these questions (or I missed something).  I can try going thru the manuals again (they're huge).

I didn't see anything about the size of the limit register or what it's supposed to do (one of my questions).

I originally asked these questions in the cpu forum, but they referred me here. (?) I guess that's an enduser desktop support forum.

I could just as well compile this with VC++, I try to make my code as multi-compiler-compatible as I can.

I am going to take another run thru the manuals and see if I missed soemthing.

Let me see if I understand the issue now. You have an extremely large function in C/C++ for which gcc is generating relative addresses (for branches I assume) that can't handle the size of the routine. Do I have this right? The compiler really ought to know better here - even if there are offset limitations in certain instruction types, the code generator knows the offset and can generate different instructions.

For jump instructions, the offset can be 8 bits or 32 bits. If a compiler knows that the offset is longer than that, it would jump to a "close" set of instructions that load the full 64-bit address and then branch to it.

IA-32e mode is not really of interest here - that's more for OS developers.

Perhaps we could help you better if you gave us a clearer description of the problem, rather than chasing down instruction format and hypothesizing unlikely scenarios.

Retired 12/31/2016

I mentioned IA32e becase I believe that's the mode windows is running on my machine.

I did submit a compiler bug report.

unfortunately, boost won't build on gcc (no Makefiles and Jam refuses to execute every coulple of versions). :-(  or I would be using it. if it were part of C++, things would be much easier.

from reading the proc manual (thank you for the new link), I understand that the 64-bit proc is really 32-bit inside somewhat, even in 64-bit modefor relative branches they are 32-bit offset (it really should be signed 64 bits) and such, so this tells me that I can't have extremely large binaries, effectively limiting the code binaries to 2GiB (the current size limit of my NSIS installer also, but not sure if this has anything to do with data). still trying to sort things out, what's 64-bit and what's 32-bit, etc. 

ahh - got it, the LSL instruction (Load Segment Limit) info says the segment limit is 20 bits. according the the lgs instruction, the seg regs are still 16 bits.

I still think 256 bits would be good.  motherboards I hear are already doing 256 bits. (now that's probably old hat with the i7-39xx). so it's not like it can't be done.

The hardware doesn't matter - the processor has the ability to do what is needed. You seem to have found a bug in gcc. There are tradeoffs for everything in processor design.

Retired 12/31/2016

Leave a Comment

Please sign in to add a comment. Not a member? Join today