Was there ever a compiler type that was just large enough to contain a memory segment?

Question

From this answer,

Hark back to the days of segmented 16-bit architectures for example: an array might be limited to a single segment (so a 16-bit size_t would do) BUT you could have multiple segments (so a 32-bit intptr_t type would be needed to pick the segment as well as the offset within it). ...

This gives me a conceptual model of a type system whereby

uintptr_t = XXXsegment_t + size_t

On a system that supports memory segmentation. Did a XXXsegment_t or the like ever get standardized into a type on such systems? Was there ever a segment_t?

Answer 1

There was never any integral type defined that corresponded to value of a segment the same way uintptr_t corresponds to the value of a pointer defined in any C compiler targeting x86 CPUs that I'm aware of. For that matter I don't know if any 16-bit segmented C compiler for x86 CPUs ever implement the uintptr_t type. You just had to know if you assigned a 32-bit long integer value to a far pointer then the most significant 16-bits of the value would be used as the segment part of the address and the least significant 16-bit as the offset part.

However there was at least one implementation of pointer-like segment types, by Borland, and of segment-like pointer types, by Microsoft. Borland's implementation used the _seg keyword to create segment pointer types while Microsoft's implementation used the _based keyword to create something called based pointers. Microsoft's based pointers were also supported by Watcom's C compiler.

The Borland implementation was the most straightforward. It allows the use of the _seg keyword just like the near, far and huge keywords in pointer types. For example you could do something like:

unsigned short _seg video_seg = 0xb800;
video_seg[80 * row + column] = character + attribute * 256;

The advantage of using a segment pointer over a far pointer here is that the variable only takes 2 bytes of space rather than 4. Also it should help the fairly primitive Borland compiler generate better code.

The Microsoft implementation used the _based keyword to based pointers. In theory these were more flexible and not specific in to the x86 segmented architecture. In fact they're still supported by current Microsoft compilers. The basic idea is that you can use the _based keyword to make a pointer "based" on some other variable. So for example you can do:

void far *video_base = 0xb8000000;
unsigned short __based(video_base) *video_seg = 0;

video_seg[row * 80 + column] = character + attribute * 256;

In practice though Microsoft implementation of based pointers in their 16-bit segmented compilers was pretty buggy and don't really offer an advantage over using far pointers to refer to segments. The were modestly used in combination with the _segname keyword to specific which segment statically allocated variables should be allocated in. For example:

unsigned char _based(_segname("OFFSCRBUF")) offscren_buffer[320U * 200];

The only other compiler that I know that did anything like this was Watcom's. They took Microsoft's based pointers and added several extensions. In particular they created a _segment keyword which is almost what you're asking for but much more inconvenient as you need to use it with both based pointers and a special :> operator. For example:

_segment video_seg = 0xb800;
unsigned short _based(void) *offset = row * 80 + column;
*(video_seg:>offset) = character + attribute * 256;

Note that all the above examples omit casts for brevity. Without the casts these code examples will all generate warnings but generate correct code.

Answer 2

To summarize what @traal linked to above, the recommended practice for DOS systems was as follows:

• Pointers are 32 bit (unsigned long)
• To get the segment for a pointer use the FP_SEG macro from DOS.H
• To get a pointer's offset within a segment use the FP_OFF macro, also from DOS.H
• Both the segment and offset are unsigned i.e. uint16_t

The macros are defined as:

#define FP_OFF(fp)  ((unsigned)(fp))
#define FP_SEG(fp)  ((unsigned)((unsigned long)(fp)>>16))

It makes sense if you think about it since a pointer_t, well, points to a location in memory. Without the segment information the actual value it points to is ambiguous. Likewise, the segment number on its own is not terribly useful¹; it only becomes useful when paired with an offset. In short, segment_t was a uint16_t but pointers were always² 32-bit³.

¹ Unless one is writing memory management code (e.g. paging to disk). In that case you would probably be working strictly with uint16_ts.

² Unless you kept all of your data in a single 64kB segement

³ This is all a bit simplified but the gist of it is that the CPU's segment and offset registers are each 16 bits wide so it makes sense to treat memory addresses as atomic 32 bit values (at the C level) with (under the hood) the 16 MSBs of an address being the segment and the 16 LSBs being the offset. Note that under this scheme a pointer_t's value is not the physical linear address (except in the 0^th segment).

Answer 3

No; size_t has to cover every possible size of a data structure which could be defined; as soon as a model allowed an array larger than 64kb, size_t had to be a 32 bit type, and there was no point in having a separate segment type.

Answer 4

For 80286 (or higher) processors, there is a Windows 3.x memory model that runs in protected mode to go beyond the real mode 1MB limit, using selectors instead of real mode segments. A block of selectors are used to access blocks of memory greater than 64KB, and incrementing a selector by 8 would point to the next 64KB block of memory. The increment value was set via a define named _AHINCR. (For real mode huge memory model, _AHINCR was 0x1000, used as the increment value for a segment register). _AHINCR - "AH" may have been used for the name because the command line switch for huge model with Microsoft compilers is /AH, while "INCR" is for increment value. For 80286, protected mode allowed for 24 bit addressing which translates into 16MB of memory.

This was superseded with 80386 and Windows 3.x support for 32 bit flat model (32 bit offsets) via win32s or winmem32. Watcom 10 C/C++ was the only compiler to support winmem32 as one of it's standard memory models.