As a bit of a PC assembler rookie, I still don't really understand the 64k boundary, nor the differences in real v protected mode, nor the speed penalties related. Could somebody please provide a little insight.

How do huge OSs like Windows Vista cope?

Only 16-bit code has a 64k limitation.

Since Win95 Windows has been a 32bit OS with a similar limitation at 4GB.

Since XP-64 Windows has been a 64bit OS with no current practical limitation (16EB).

There is no 64k limitation if you use huge model (or 286's 16-bit pmode) unless you mean the size of a real-mode segment, but you can use more than one.

Real mode existed before RAM was cheap and common, so you could only access 1 MB of RAM (way way way more than anybody had at the time). Pmode came about because it was too easy to crash the machine with badly-written code. I think pmode is vaguely slower, but then again, they've geared the cpu hardware for pmode ever since 486s or so, so it's moot. Almost no OSes use real mode or the BIOS anymore (except DOS, and even that supports pmode extenders).

Segments are an abomination. I don't like to use ANY. Using more than one segment to break the 64k (or any) limitation is hardly a good thing, better to go to the next bit size.

What's so bad with segments? I think we should have added segments to 32-bit instead of going 64-bit. Less problems with "new architecture".

Borsuc: I think you must be the only person in the world to think that segmentation is okay.

I'm not quite sure what the OP was trying to say above. Perhaps some old information from some ancient website that someone thought was the current situation?

Fortunately segmentation is now dead, may it RIA (rest in agony).

Why? Not to mention, it makes sometimes code organized in groups. Of course segments in 16-bit suck because the address range is too limited. With 4GB chunks at a time, that's not a problem anymore.

Moving to 64bit addressing is the right thing to do. Returning to segmentation (even with 32bits) is the wrong thing to do.

Running a protected mode OS with segmentation active is a nightmare (slow, prone to bugs, and just ugly to program). Just look at the disaster that was known as 80286 protected mode OSes.

There is no reason it would be worse. If done properly you could even pretend segments aren't there -- just the "higher part" of the register, and the "lower part" of the register (like ah and al).

ah = 8-bit segment
al = 8-bit address

Even if you want a FLAT addressing space, it would make no difference, except in assembly, where in my opinion, would make code somewhat more organized (by organizing data chunks into segments). Again, the 16-bit segments sucked because it wasn't even a multiple of 65536. Wrongly done IMO.

I leave it to you to find a "proper" way to code a protected OS with segmentation. No one else was able to do it for the '286. I also tried all those years back, and I have a working version still active in one site, but it is an ugly monster. I would never willingly choose to return to segmentation, ever.

> I still don't understand the 64k source boundary debate.

Problem affects only DOS UNREAL code, OTOH not proper 32-bit PM code under DOS.

> How do huge OSs like Windows Vista cope?

They don't use UNREAL and require at least 2 GiB RAM

> There is no 64k limitation if you use huge model (or 286's 16-bit pmode)

NOT true, and FASM doesn't have any "huge model" anyway.

> unless you mean the size of a real-mode segment, but you can use more than one.

NO thanks

> Fortunately segmentation is now dead, may it RIA (rest in agony).

hehe ...

Moving to 64bit addressing is the right thing to do.

hehe ... and 256 bit ASAP

> Returning to segmentation (even with 32bits) is the wrong thing to do.

Then don't do this

> Running a protected mode OS with segmentation active is a nightmare
> (slow, prone to bugs, and just ugly to program).

Right.

> Just look at the disaster that was known as 80286 protected mode OSes.

Right. 80286 should have deleted the 64 KiB limit rather than inventing the "protected" mess

But doesn't 32-bit and even 64-bit PCI still have a 64 KiB DMA limit ?

This came from the fasm wikipedia page:

"Due to its Titan OS origins, FASM originally only ran in raw 32-bit "flat real" mode. Optional DPMI support was added later on. Recently, this was removed in favor of DPMI exclusively (due to losing the battle with the 64k code segment). However, the speed lost here is minimal, and DPMI (which FASMD always used) is better for compatibility with modern OSes and emulators".

This is precisely the bit that confuses me. I have written machine code programs for the Intel CPUs, so I have uses segmented addressing. As long as the object file isn't longer than 64k then it's precisely no problem because I just set the segment registers at the start and then forget about them. It makes a DOS .com executable. If I understand correctly, this is the fastest and most compact way of making DOS executables.

Now, I was looking for a 'big' assembler that cuts through all the segmentation bull because I thought it was possible. So I don't understand why the wikipedia entry suggests that even Fasm falls foul of it... wasn't the whole point of fasm to overcome that? I also don't like the sound of the suggestion that DPMI mode is, for some unexplained reason, slower than... whatever the other modes are, I've tended to side-step these issues, but more education on the matter would be most welcome.

So, can somebody shed any light on what it says in Fasm wikipedia entry about the 64k code segment? And, if I use 32bit mode is there some kind of penalty?

Lastly, what would be the difference between using Fasm and using Borlands Turbo assembler in Idea mode and selecting the .huge memory model?

I also found this in the Digital Mars documentation:

"Note: 4GB is a theoretical maximum. Under DOS or XMS, the maximum extended memory is limited by BIOS function calls to just under 64MB. The DOSX 32-bit DOS extender can handle up to 3GB, because it allocates 3/4 of the available extended memory. There is no system that supports 4GB of memory at this time.

To run in 32-bit protected mode, you need a 32-bit DOS extender. The DOSX memory model (-mx) is compatible with the DOSX 386 DOS extender. The Phar Lap memory model (-mp) is compatible with the Phar Lap 32-bit DOS extender, available from Phar Lap".[/i]

This again suggests there is no simple "give me the memory" option?

Are things different if you write the OS boot-code yourself? I've done this too, but it was a 64k model again. Surely if you do this then you're not working under DOS.... but why do they say NT is a does extender? Is it that hard to get the resource limitation to just take a hike?

See what I mean? It's like even after all these years the 80386 resource limitations still seem to be an ongoing issue.

I'm still annoyed we didn't just dump Intel and adopt the Alpha CPU when we had the chance. That was 64Bit, faster FPU and no problems.

The source of nonsense

> This is precisely the bit that confuses me.
> I have written machine code programs for the Intel CPU

Assembler = ? OS = ?

> It makes a DOS .com executable. If I understand correctly, this
> is the fastest and most compact way of making DOS executables.

Compact: YES | Fastest: maybe

> wasn't the whole point of fasm to overcome that?

YES.

> I also don't like the sound of the suggestion that DPMI mode is

DPMI sucks

> slower than...

Paging is slower than non-Paging ... by 5% or anyone bothered to test

Proper PM is slower than UNReal ... or isn't ?? Tomasz ???

> So, can somebody shed any light on what it says in Fasm wikipedia entry

{{delete}}

> Lastly, what would be the difference between using Fasm and using
> Borlands Turbo assembler in Idea mode and selecting the .huge memory model?

FASM is more free.

> I also found this in the Digital Mars documentation:

> maximum extended memory is limited by BIOS function calls to just under 64MB.

Wrong.

> There is no system that supports 4GB of memory at this time.

Right.

> To run in 32-bit protected mode, you need a 32-bit DOS extender.

Wrong. There are 1'000'000'000 other options.

> This again suggests there is no simple "give me the memory" option?

There is. Enter PM with both CS and DS having base ZERO and limit 4 GiB ($FFFF'FFFF), don't enable paging.

> Are things different if you write the OS boot-code yourself?

Don't fight with DPMI

> you're not working under DOS.... but why do they say NT is a does extender?

Because some notable Wikipedians think they must edit everything (including DOS) daily from their NT although they have no idea about DOS at all

> after all these years the 80386 resource limitations still seem to be an ongoing issue.

NO. 80386 deleted the 64 KiB segment limit.

Excellent! Thank you so much for taking the time to answer my many questions DOS 386!