Subj : NASM segment registers- again
To   : All
From : Robin Sheppard
Date : Sat Oct 20 2001 09:21 pm

This is a re-post of a message I posted recently.  I didn't get any 
replies, so was wondering if it even got out.  On the assumption that 
it probably didn't, I'm posting it again.
-------

Does anyone know how to load segment registers at runtime using NASM,
when generating COFF output?

Specifically, I'm trying to port some 16-bit timer-handler code I
wrote so it'll run under DJGPP.  The assembly code has three
functions, _hooktimer, _unhooktimer, and newtimer.  The first two are
global symbols, so my C code can use them to (you guessed it) hook and
unhook the timer.  The newtimer procedure is the actual interrupt
handler, and all it does currently is send an end-of-interrupt,
execute STI, and exit.

It's supposed to increment a global variable called _count, but since
the function is asynchronous, I can't rely on the value of DS; I have
to load it myself.  If I don't, it'll merrily increment random memory
locations until my machine crashes.  This is what I can't figure out
how to do.

I've tried moving into a reg with a line like

  mov ax, .data

where my data section is declared like so:

  section .data data

but when I assemble it then, NASM complains about ".data" (or "data";
I tried that too) being an undefined symbol.  I even tried using

  mov ax, seg _count

but I got some error about the COFF format not supporting non-32-bit
relocations, whatever that means.  Thing is, _count is declared as a
dword, and my code, data, and stack segments are all 32-bit (as is
default for COFF objects), so I don't see how it concludes non-32-bit
_anything_.

The only way I can think of to get around this is to create an alias
data descriptor for my code segment, and use that to write the value
directly into my code segment at runtime.  Not only does this seem
like a kludge, but it also seems to be bad programming practice.
Isn't there some mechanism similar to

  mov ax, DGROUP

in MASM/TASM that I can use for this purpose?

.... Religious error: [A]tone, [R]epent, [B]lame Satan, [F]log thyself

--- EzyBlueWave V1.48g0 01fd0192
 * Origin: Milky Way, Langley, BC [604] 532-4367 (1:153/307)

.