flat assembler
Message board for the users of flat assembler.
![]() Goto page Previous 1, 2, 3, 4 Next |
Author |
|
DOS386 18 Jan 2009, 13:31
> to (e.g.) DS, flat descriptors for ES, FS and GS are still in effect.
Right ... loading one segment register in RM destroys the higher limit in the one only ... and it can't be recovered anymore in RM. |
|||
![]() |
|
baldr 18 Jan 2009, 17:33
DOS386,
That's exactly what I've meant by "more and more real". ![]() |
|||
![]() |
|
neville 18 Jan 2009, 18:28
baldr wrote: DOS386, Do you actually have experience of this? Because in my experience it is not the case. For example in FAMOS I setup "Flat Real Mode" once only at boot time, set 32-bit limits etc and then never touch them again. FAMOS normally runs with (RM) DS=0000, but DS gets changed extensively by "Limited Legacy Programs" (de-DOS'd old DOS games etc in FAMOS). Then after the LLP has run, all FAMOS does is the simple 16-bit xor ax,ax / mov ds,ax and the 32-bit limits are still there. My debugging also shows that the 32-bit limits are also still in effect while the LLP's are running. _________________ FAMOS - the first memory operating system |
|||
![]() |
|
revolution 19 Jan 2009, 10:45
In real mode address calculation works similar to this:
<segment register>*16+<16bitAddress>+<hiddenSelectorOffset> And each time the segment register is updated in RM the hidden selector part is not changed. At CPU reset the hidden selector part is initialised with a 64K limit and an offset of 0. When using Unreal mode it is common to change the limit to 4G and leave the offset at 0. I know of no way in RM mode to change the hidden selector portion of each segment register. |
|||
![]() |
|
neville 19 Jan 2009, 19:14
That makes perfect sense revolution, and fits with my experience, but remains at variance with baldr's assertions above.
_________________ FAMOS - the first memory operating system |
|||
![]() |
|
revolution 19 Jan 2009, 19:28
One thing I forgot to mention is that in RM mode the address can also be 32bit when using Unreal mode or with an operand override prefix in RM. So it becomes this:
<segment register>*16+<16/32bitAddress>+<hiddenSelectorOffset> And also the limit check is done in the background to cause an exception if the calculation is above the hidden selector limit. Note that the limit check is done before adding the selector offset. With a 4G limit then no exception can be generated because the limit cannot be exceeded. |
|||
![]() |
|
baldr 19 Jan 2009, 23:12
neville & revolution,
My experience with unreal mode is pretty outdated (10+ years ago), probably what I've said was right in some variant of 486 architecture (Am5x86/Cx5x86? They were pretty popular those days). Sorry for misinformation, I should have checked it better. |
|||
![]() |
|
neville 20 Jan 2009, 19:24
ok baldr, no problem, but I hope you're also wrong about those Cyrix chips and other "486 variants" because if you're right, FAMOS could easily crash on them
![]() _________________ FAMOS - the first memory operating system |
|||
![]() |
|
LocoDelAssembly 20 Jan 2009, 19:39
Some time ago a user of the DOS version of FASM reported that it wasn't working on his Cyrix without DPMI but as far as I can recall Tomasz managed to change the code in order to make it compatible with Cyrix.
[edit] Here is the link: http://board.flatassembler.net/topic.php?t=3946 . BTW, seems that there was no fix other than using DPMI ![]() |
|||
![]() |
|
baldr 20 Jan 2009, 23:15
LocoDelAssembly,
Probably his DPMI didn't reload descriptor on fault. |
|||
![]() |
|
LocoDelAssembly 21 Jan 2009, 00:09
No, the problem was that fasm wasn't running in DPMI mode when the processor was in real mode so it was always switching to unreal mode which as the thread suggest is unsupported by 486SLC and some emulators like Bochs.
The freeze was when DPMI wasn't used, not when it was. |
|||
![]() |
|
revolution 21 Jan 2009, 02:05
Is it that the CPUs that don't/won't support the unreal mode have a hard coded limit of 64K when in RM. That is, do they ignore the hidden selector limit setting updated by PM? Or, is it that the code selector setting for 32bit code is ignored? Or, is it both?
It would be interesting to compile a list of the CPUs that have this "feature". |
|||
![]() |
|
LocoDelAssembly 21 Jan 2009, 02:23
Quote:
This one. Tomasz Grysztar wrote: It fails when the code bitness bit is ignored in real mode. On Intel and AMD processors when you switch back to real mode with the descriptor in CS having the code type set to 32-bit, it still executes the 32-bit code. When processor (like this Cyrix) ignores these settings of code descriptor in real mode, it won't work. ( http://board.flatassembler.net/topic.php?p=28993#28993 ) BTW, you can salute yourself one post below the one I quoted ![]() |
|||
![]() |
|
revolution 21 Jan 2009, 02:25
Oh shit, a 3.5 year old post. I completely forgot. Thanks for the reminder.
|
|||
![]() |
|
neville 21 Jan 2009, 19:35
revolution wrote: Is it that the CPUs that don't/won't support the unreal mode have a hard coded limit of 64K when in RM. That is, do they ignore the hidden selector limit setting updated by PM? Or, is it that the code selector setting for 32bit code is ignored? Or, is it both? _________________ FAMOS - the first memory operating system |
|||
![]() |
|
revolution 22 Jan 2009, 00:27
neville wrote: All 64-bit CPU's because there is no "long mode" equivalent of unreal mode... This is tragic. I hope one day this will change ... |
|||
![]() |
|
neville 23 Jan 2009, 02:31
revolution wrote:
![]() _________________ FAMOS - the first memory operating system |
|||
![]() |
|
revolution 23 Jan 2009, 02:51
What advantage is to be gained by 64bit unreal mode? Sure, you don't have the paging mechanism involved, but I see that as a detriment rather than an advantage.
The fragmented memory space can become tricky to deal with. You will have LFB's and I/O buffers messing up the ability to have contiguous chunks of RAM at your disposal. With just a small amount of programming to set up the page tables I think it is worth it to get into a memory environment where things are laid out more logically. Yes, this is no longer 1-1, it is a much nicer improvement over the simple 1-1 scheme. |
|||
![]() |
|
neville 23 Jan 2009, 03:54
Unreal mode or Flat Real mode has several advantages for me. It provides a convenient no-hassle easily set-up environment for processing bulk data held in a linear 32-bit address space, up to 4 gigabytes. For example, it gives me direct access to all BIOS interrupts which saves a lot of time if you don't have to first write, then test and then debug your own I/O routines, for example. (16-bit code is not a problem - it works with 32-bit addresses just fine)
I guess I see protected mode as being "over-protective". We all use computers to do different things, and if somebody wants to run their 64-bit CPU in the highest possible "privilege" with all physical memory directly addressable by a 64-bit register, why shouldn't they be able to? But X86-64 has made this impossible. Why did they do that? Now back to reality, I don't understand why 1-1 mapping has to mess up memory (if thats what you're saying). Couldn't all buffers and page tables etc be located in, say, a dedicated low memory area, so that all memory above the buffers etc is a single contiguous chunk? Quote: With just a small amount of programming to set up the page tables I think it is worth it to get into a memory environment where things are laid out more logically _________________ FAMOS - the first memory operating system |
|||
![]() |
|
Goto page Previous 1, 2, 3, 4 Next < Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2025, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.