Re: referring to segments other than DS - how?
- From: Frank Kotler <fbkotler@xxxxxxxxxxx>
- Date: Fri, 29 Feb 2008 19:30:35 GMT
Pop Tart wrote:
....
I had to move the offset to _bss into DS for the function 3Fh,
This is more of a Masm question - Nasm doesn't use the "offset" keyword - but I can't imagine that moving "offset" anything into a segreg is right... although it may work... it's an "immediate"... I assume when you use ".data" and ".data?", Masm creates "_data" and "_bss" internally???
In an earlier post, you observe "the CPU doesn't really know about the bss section". Quite right. The assembler converts our names - "bss" - into numbers, but these are only in terms of "nineteen segments higher than text". We don't know until load-time what the actual number will be. Dos loads us at a segment of its choosing - presumably the first/lowest one that's free - the loader does "FIXUP"s to patch "mov ax, @data" to its final number. The CPU *does* use a segment register and an offset to form an address - even in pmode! - but it doesn't know or care whether cs and ds are the same or different - so long as segreg:offset finds the "right" code/data.
I usually do .com files for dos. Although Nasm will allow "section/segment .bss", etc. everything is in one 64k segment - .text first, followed by .data, followed by .bss. When dos loads a .com file, cs, ds, es, and ss are all set to the chosen segment. The first 256 bytes are "PSP" (Program Segment Prefix - a data area that dos creates and uses - we can use parts of it, too).. Your fictional "section .text" starts at offset 100h into the segment (no options on entrypoint), followed by "section .data", etc. Initial sp is at 0FFFEh - it started at 0, but dos - the loader - has pushed a zero. So if we "ret", we go to offset 0 in this segment - the beginning of PSP - which is CD 20 (hex) - int 20h - the (an) "exit to dos" interrupt.
When dos loads an .exe file, es and ds are set to PSP again, but this is not the same as cs, and not the same as "@data" (which is why we need to load ds(and es) at program start, before we can find our data). It is common to combine data and bss - a linker option, I think (different linkers give different executable sizes, sometimes). If they're combined, "first_data_var" and "first_bss_var" would have different offsets, if you've got separate segments, they'd both be at offset 0, but the segreg involved would have to be set - by you - "assume" does *not* do this - just tells Masm that it's been done - if you've got a variable in one segment, and "assume" another, Masm will correct the offset if it'll reach, I think(?).
We haven't discussed ss:sp much... In Nasm, you'd want a "segment stack stack"/ "resb ????". The first "stack" is just a name, and could be anything, the second "stack" is an "attribute", and tells Nasm to tell the linker this is where we want our stack. Masm may be doing this "behind your back", if you aren't doing it explicitly. The loader than loads ss and sp for us. There's an example in the Nasm manual that explicitly loads ss and sp, but this is *not* necessary, and I think it's a Bad Idea - I've seen a nicely aligned stack turn into a misaligned one - let dos do it!
So... the CPU *does* depend on segments, but counts on the programmer, assembler, linker, and loader to conspire to provide it with the right numbers.
If you "need" multiple segments, it's time to graduate to 32-bit code, IMO, but if you want to experiment, step though it with a debugger and observe what numbers the actors have conspired to produce...
Hope that "clarifies" more than it "confuses"...
Best,
Frank
.
- References:
- referring to segments other than DS - how?
- From: Pop Tart
- Re: referring to segments other than DS - how?
- From: Pop Tart
- referring to segments other than DS - how?
- Prev by Date: Re: for the close of all fission nuclear reactor in the world
- Next by Date: Re: [OT] the lack of humility
- Previous by thread: Re: referring to segments other than DS - how?
- Index(es):
Relevant Pages
|
