flat assembler
Message board for the users of flat assembler.

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

Author
Thread Post new topic Reply to topic
vapourmile



Joined: 30 Mar 2007
Posts: 4
vapourmile
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?

_________________
You're groovy. I think you're just great!
Post 01 May 2009, 17:32
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17344
Location: In your JS exploiting you and your system
revolution
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).
Post 01 May 2009, 17:35
View user's profile Send private message Visit poster's website Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo
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).
Post 02 May 2009, 10:10
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17344
Location: In your JS exploiting you and your system
revolution
rugxulo wrote:
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.
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.
Post 02 May 2009, 11:54
View user's profile Send private message Visit poster's website Reply with quote
Borsuc



Joined: 29 Dec 2005
Posts: 2466
Location: Bucharest, Romania
Borsuc
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".
Post 02 May 2009, 20:49
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17344
Location: In your JS exploiting you and your system
revolution
Borsuc: I think you must be the only person in the world to think that segmentation is okay. Shocked

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).
Post 03 May 2009, 02:54
View user's profile Send private message Visit poster's website Reply with quote
Borsuc



Joined: 29 Dec 2005
Posts: 2466
Location: Bucharest, Romania
Borsuc
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.
Post 03 May 2009, 15:36
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17344
Location: In your JS exploiting you and your system
revolution
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.
Post 03 May 2009, 15:44
View user's profile Send private message Visit poster's website Reply with quote
Borsuc



Joined: 29 Dec 2005
Posts: 2466
Location: Bucharest, Romania
Borsuc
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.

_________________
Previously known as The_Grey_Beast
Post 03 May 2009, 16:07
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17344
Location: In your JS exploiting you and your system
revolution
Borsuc wrote:
If done properly ...
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.
Post 03 May 2009, 16:11
View user's profile Send private message Visit poster's website Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
> 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 Laughing

> 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 Sad

> 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 Laughing

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

Then don't do this Laughing

> 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 Sad

But doesn't 32-bit and even 64-bit PCI still have a 64 KiB DMA limit ?
Post 05 May 2009, 12:41
View user's profile Send private message Reply with quote
vapourmile



Joined: 30 Mar 2007
Posts: 4
vapourmile
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.

_________________
You're groovy. I think you're just great!
Post 05 May 2009, 20:10
View user's profile Send private message Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
vapourmile wrote:
This came from the fasm wikipedia page


The source of nonsense Laughing

> 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 Sad

> slower than...

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

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}} Laughing

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

> 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 Smile

> 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 Wink

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

NO. 80386 deleted the 64 KiB segment limit.
Post 06 May 2009, 02:38
View user's profile Send private message Reply with quote
vapourmile



Joined: 30 Mar 2007
Posts: 4
vapourmile
Excellent! Thank you so much for taking the time to answer my many questions DOS 386!

_________________
You're groovy. I think you're just great!
Post 06 May 2009, 17:33
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on YouTube, Twitter.

Website powered by rwasa.