Index
> DOS > initial cs register is not 100h? |
| Author |
|
|
shoorick 31 Dec 2012, 13:00
ip (/index/ instruction pointer) has initial value of 100h
cs keeps code segment, where com file has been loaded, its value depends on current system memory situation: so more memory used by drivers and tsrs, so larger value has the new segment. full physical address can be calculated as cs*16+ip near jumps/calls change only ip, cs for them stay unchanged Last edited by shoorick on 03 Jan 2013, 17:14; edited 1 time in total |
|||
31 Dec 2012, 13:00 |
|
|
kty11 31 Dec 2012, 13:41
shoorick wrote: ip (index pointer) has initial value of 100h now I got it thanks .com file loaded not on 100h but cs:100h and ip cares about only inside cs.  _________________ since 1990 November 4th |
|||
|
31 Dec 2012, 13:41 |
|
|
ACP 31 Dec 2012, 20:38
Just to clarify:
IP = instruction pointer NOT the index pointer (x86 is using different registers for index pointers) In real mode the address that CPU executes is controlled by CS:IP pair of registers as pointed out already and CS "cares" only about CS and IP register "cares" about value IP but you as a programmer must take care about both. Also keep in mind that com files has 64kb limit and there is only single segment for stack, data and code. This means that you can use CS to setup properly DS and ES segment registers to point at your code segment which in turn is data segment as well for example. Happy New Year! |
|||
|
31 Dec 2012, 20:38 |
|
|
kty11 01 Jan 2013, 01:29
ACP wrote: Happy New Year! happy new year! _________________ since 1990 November 4th |
|||
|
01 Jan 2013, 01:29 |
|
|
AsmGuru62 01 Jan 2013, 12:35
The beauty of COM file is that all segments are already set, so programmer does not need to do it.
|
|||
|
01 Jan 2013, 12:35 |
|
|
edfed 03 Jan 2013, 14:33
not all. some of them (GS for example) aren't assumed to be set to a particular value depending on the dos version.
|
|||
|
03 Jan 2013, 14:33 |
|
|
ACP 05 Jan 2013, 21:28
Ok to get things straight:
DOS does not use FS or GS or any other 386 registers (like EAX or TSS). Thare are two exceptions I can think of right now: 1) running DOS under some task switcher in Protected Mode like DesQView or 16/32bit Windows (like 3.0 for example) 2) running your code within DOS Extender - some DOS extenders supported even COM files written directly in assembly language out of the box like Pro32 for example Basically COM file format (since it is a plain binary just loadded at 100h offset to make room for PSP structure in the same memory segment) has roots in CP/M and that is why it so simple. At the time is has been designed and DOS loader for COM files has been written noboudy had though about 386 features because it wasn't even available back than. So to not complicate things further here is a setup of segment registers when original, plain MS-DOS loads COM file into memory: CS,DS,ES,SS = code segment with PSP SP = FFFEh (the last word in the program segment) IP is being set to 100h And this is how all DOS clones and MS-DOS/PC-DOS itself behaves up to 6.x version. Hope this helps |
|||
|
05 Jan 2013, 21:28 |
|
|
baldr 05 Jan 2013, 22:28
ACP,
sp can be different in a memory-scarce scenario. It is loaded (before push 0) with one more than highest address available in ss segment, for regular situation it's (1)0000. There are sources available, you may read them for some information. fs was used at least in HIMEM.SYS 3.2, for fast m/m transfers in unreal mode (it even retains that mode afterwards). DESQview was probably the most virtualizing shell ever. Back to the topic: nobody have to speculate on loader's behavior. Let's write (again) register dumping .COM and try it in every available environment, with some posts of results. |
|||
|
05 Jan 2013, 22:28 |
|
|
ACP 05 Jan 2013, 22:42
I'm glad you did not point out that (some) BIOSes also use unreal mode before HIMEM.SYS does during system startup
I actually forgot about HIMEM but since unreal mode requires you to switch to protected mode first it is a very special case. Don't know which sources are you actually referring too (except HIMEM.SYS sources which indeed has been released) but you can always PM me. I just hope you are joking about checking every possible environment |
|||
|
05 Jan 2013, 22:42 |
|
|
baldr 05 Jan 2013, 23:36
ACP,
The sources I've mentioned was 3.30 and 6.0, they're available. I didn't refer to BIOS because we were talking about DOS, aren't we? And I don't think we have to discuss SMM and other peculiar techniques implemented in BIOS. Every possible environment? Heh, I'd keep logs with dumps of registers' values on entry to MBR, just for kicks. They even have stack dump for backtracking into those BIOSes, ranging from AWARD thru AMI then MRBIOS and such. Heh, several NICs (3Com, Intel, Compex and now-ubiquitous Realtek) PXEs were the objects for examination (and dissection too). |
|||
|
05 Jan 2013, 23:36 |
|
|
ACP 05 Jan 2013, 23:51
Quote: I didn't refer to BIOS because we were talking about DOS, aren't we? And I don't think we have to discuss SMM and other peculiar techniques implemented in BIOS. In such case you should also make clear if we are talking about DOS running in plain real mode or in some form of protected mode Please ignore it - I'm just joking  |
|||
|
05 Jan 2013, 23:51 |
|
< Last Thread | Next Thread > |
Forum Rules:
|