where [BITS 32] directive?
in [ASM]
|
Prev: NASM HelloWorld - DOS
Next: ELF loading
From: Rod Pemberton on 14 Aug 2007 03:33 "Frank Kotler" <fbkotler(a)verizon.net> wrote in message news:dE0wi.1833$tU4.973(a)trndny03... > > Also, although I don't see > > much NASM code without the brackets, technically you should be using BITS 32 > > or BITS 16 without brackets. > > Why do you say that? There's a difference between "section .text" and > "[section .text]" - the former is a macro which expands to the latter > *and* sets "__SECT__". "bits 32" is a macro that expands to "[bits 32]", > but has no side effects. What's the advantage? > Actually, I was hoping you could tell me... It's what the NASM manual says to do: From, Chapter 5: "NASM's directives come in two types: _user-level_ directives and _primitive_ directives. Typically, each directive has a user-level form and a primitive form. In almost all cases, we recommend that users use the user-level forms of the directives, which are implemented as macros which call the primitive forms." From the end of 5.1: " The `BITS' directive has an exactly equivalent primitive form, `[BITS 16]' and `[BITS 32]'. The user-level form is a macro which has no function other than to call the primitive form." So, even though they are exactly equivalent at present, the manual recommends using the BITS 32 form... I'd suspect that this implies someone considered the rare possibility that they might be modified in how they work in future implementations. Rod Pemberton
From: Rod Pemberton on 14 Aug 2007 03:33 "Frank Kotler" <fbkotler(a)verizon.net> wrote in message news:Hj0wi.1312$Gz4.2(a)trndny05... > Rod Pemberton wrote: > > ... > > Yeah, but if he wanted the jump in BITS32 he should be able to put an > > operand size override prefix, o16, right? Like so: > > > > [BITS 32] > > o16 jmp 08h:clear_pipe ; Jump to code segment, offset > > clear_pipe: > > mov ax, 10h ; Save data segment identifyer > > mov ds, ax > > I guess that would work (I've not run it). Why would he want to increase > the confusion? > You'd have to ask him. He just wanted to know why the code didn't work with BITS 32 placed elsewhere. On the other hand, I had once piece of code where the break between the 16-bit and 32-bit segment wasn't so clear as this. NASM automatically emitted some overrides, but not others. It took a while playing around with a16,a32,o16,o32, to find the minimal overrides and an acceptable place to separate the sections. Rod Pemberton
From: opexoc on 14 Aug 2007 05:05 > Or is it, > 1) setting cr0 bit 0 (PE) allows switching into protected mode, but doesn't > do the switch > 2) reloading CS with a selector instead of a segment actually does the > switch into protected mode > 3) the bit in the descriptor decides if it's 32-bit or 16-bit protected mode > Thanks for this strite answer. Thanks everyone for interesting this subject. Another question: Is it really necessary to enable A20 line to enter PM? Some tutorials write that it is needed, but others not. For example there: http://www.osdever.net/tutorials/brunmar/tutorial_02.php The author doesn't do this ( maybe for simplicity ) Wiktor.
From: Frank Kotler on 14 Aug 2007 07:48 Rod Pemberton wrote: > "Bx.C / x87asm" <email.address(a)is.invalid> wrote in message > news:f9q9bh$ms$1(a)aioe.org... > >>>Yeah, but if he wanted the jump in BITS32 he should be able to put an >>>operand size override prefix, o16, right? Like so: >>> >>>[BITS 32] >>>o16 jmp 08h:clear_pipe ; Jump to code segment, offset >>>clear_pipe: >>>mov ax, 10h ; Save data segment identifyer >>>mov ds, ax >> >>so instead of: >> >> EA,xx,xx,08,00 16-bit... jmp 0008:clear_pipe >> >>you have it create: >> >> 66,EA,xx,xx,08,00 >> >>ummmm,... no! > > > No, it creates (due to BITS 32...): > > 66,EA,xx,xx,yy,yy,08,00 > > Which is told by 0x66 to execute as: > > EA,xx,xx,08,00 > > I.e, the dword offset reduced to word offset... Correct? Seems right to me. > (BTW, it does work...) If it seems right to the CPU, it's right! Best, Frank
From: Frank Kotler on 14 Aug 2007 08:15
Rod Pemberton wrote: > "Frank Kotler" <fbkotler(a)verizon.net> wrote in message > news:dE0wi.1833$tU4.973(a)trndny03... > >>>Also, although I don't see >>>much NASM code without the brackets, technically you should be using > > BITS 32 > >>>or BITS 16 without brackets. >> >>Why do you say that? There's a difference between "section .text" and >>"[section .text]" - the former is a macro which expands to the latter >>*and* sets "__SECT__". "bits 32" is a macro that expands to "[bits 32]", >>but has no side effects. What's the advantage? >> > > > Actually, I was hoping you could tell me... It's what the NASM manual says > to do: > > From, Chapter 5: > > "NASM's directives come in two types: _user-level_ directives and > _primitive_ directives. Typically, each directive has a user-level > form and a primitive form. In almost all cases, we recommend that > users use the user-level forms of the directives, which are > implemented as macros which call the primitive forms." > > From the end of 5.1: > " The `BITS' directive has an exactly equivalent primitive form, > `[BITS 16]' and `[BITS 32]'. The user-level form is a macro which > has no function other than to call the primitive form." > > So, even though they are exactly equivalent at present, the manual > recommends using the BITS 32 form... I'd suspect that this implies someone > considered the rare possibility that they might be modified in how they work > in future implementations. Okay, that's probably a good reason to use the "user-level" form (some of us might find that term insulting :) In the case of "section", we can deliberately use the difference to our advantage... Say, in a macro that could be inserted in "any old section"... section .text ; sets __SECT__ to ".text". [section .something] ; changes section, but doesn't set __SECT__ ; something in that section __SECT__ ; back to whatever section we were in I don't foresee anything like that happening with "bits", but... won't hurt to be prepared... Note the "bits 32" *must* have a space in it. Nasm thinks "bits32" is just an unused label... which has thrown a few people for a loop. "use32", no space - this is a macro equating to "bits 32", besides being a section attribute... Maybe we should define "bits32" as "[bits32]", also(?). In the case of "[extern]", "[global]", and "[common]", the "raw" form takes only a single parameter. The "user-level" forms accept multiple parameters. So "bits" is kind of an exception in that there's no difference. So it's probably good advice to use the "user level" form, unless you specifically *don't* want side effects, you're right. Best, Frank |