Re: bits 32 oddities in NASM

James Daughtry wrote:

....
I was experimenting to see if I could use DOS interrupts with 32-bit
registers.

Yeah, you can. It was the "bits 32" that was killin' ya, not the 32-bit registers. You can use 32-bit addressing modes in 16-bit code (but you have to keep the total offset within the 64k-1 limit). This can be *very* handy.

But, since dos (and bios) interrupts are 16-bit code, Nasm needs to be generating 16-bit code to operate there. This means that using 32-bit registers will require an "override prefix byte" - 66h for an operand size, and 67h for address size. Nasm will generate these, where needed - you don't have to do it. There's a slight "penalty" in terms of "bloat" and speed, but the gains are often worthwhile.

I know I can do it with 16-bit registers, to some extent.

Yeah. You can use 16-bit registers - even addresses - in 32-bit code, too. Same override bytes. This is less often useful.

Most likely because there's some hidden emulation layer that caters to
stupid people who try to write DOS in Windows. ;-)

Yes, there's an emulation layer for people who realize that not *everything* requires a 32-bit cartoon interface. :)

Are interrupts real
interrputs on Windows XP? Or do they end up calling a Win32 function?

Well, the interrupts are "real", I guess - the CPU stops what it's doing and jumps to the code pointed to by the interrupt vector table. But the code the IVT points to... may end up calling a "Windows function" - possibly at a lower level then the usual user-level API.

To be perfectly honest, I wanted to find a convenient way to do I/O
without resorting to the C library or the evil Win32 API. Interrupts
are simple and relatively easy to use. The C library is very simple and
easy to use, for me, but I can imagine it being somewhat bloated for an
assembly program. I *hate* the Win32 API with a well honed passion,
even for simple things, and I try to avoid it. :-)

Well, if the "fake dos" emulation hides it behind your back, it's at least painless. I'd go ahead and use the dos interrupts and not worry about what goes on after that. Would you know in "real dos"?

If you really want to avoid the Win32 API, Linux or BSD would do that...

Best,
Frank
.

Relevant Pages

  • Re: bits 32 oddities in NASM
    ... extender or switch to pm yourself - and *then* dos interrupts won't work... ... stupid people who try to write DOS in Windows. ... without resorting to the C library or the evil Win32 API. ...
    (alt.lang.asm)
  • Re: Linux syscalls
    ... > A device driver or a rewrite of DOS could permit this, ... really "DOS inside Windows" or "Windows inside DOS"? ... > DOS interrupts are revectored... ... if you re-write DOS to use the _Windows device drivers_ ...
    (alt.lang.asm)
  • [PATCH 6/11] 2.6.17-rc5 perfmon2 patch for review: new i386 files
    ... * context is locked and interrupts are masked. ... PMU interrupt is masked. ... PMC and PMD registers are live in PMU. ...
    (Linux-Kernel)
  • Re: [PATCH] Documentation: Make fujitsu/frv/kernel-ABI.txt 80 columns wide
    ... -The internal FRV kernel ABI is not quite the same as the userspace ABI. ... -most of them do not have any scratch registers, thus requiring at least one general purpose ... +single-stepping will blithely go on stepping into things like interrupts. ... -to read and once to write), we don't actually disable interrupts at all if we don't have to. ...
    (Linux-Kernel)
  • Re: Tutorial for beginners
    ... I did one of my first assembly programs in DOS. ... Basically assembly is moving data into registers... ... The n command in DEBUG is the NAME command. ... > The Art of Assembly Language Programming. ...
    (comp.lang.asm.x86)