Date:	Thu, 25 Feb 1999 11:14:51 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Dave Bird <dave AT xemu DOT demon DOT co DOT uk>
cc:	djgpp AT delorie DOT com
Subject:	Re: I just wanted to assemble this old program under NASM....
In-Reply-To:	<1lGPMoAteC12EwsX@xemu.demon.co.uk>
Message-ID:	<Pine.SUN.3.91.990225111426.2772J-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp AT delorie DOT com

On Wed, 24 Feb 1999, Dave Bird wrote:

>  At the moment there is a program prefix at START: which defines
>  the following things.  (1) Sets up stack pointer and segment 
>  registers (2) If true PM it would manage the transition from
>  16Bit RealMode start-up through calling DPMI to set up the
>  protected mode segments and enter protected mode (3) It uses
>  XMS [or DPMI] to allocate about 40MBytes locked and provide
>  a simple 32bit variable pointing to it (4) then it calls ASM_MAIN.
>  On return it de-allocates and exits.
> 
>  Next it defines wrappers for various DOS calls with convenient
>  register-passing conventions for WriteChar, WriteString,
>  ConvNum, WriteNum and so forth. It also has a "Load" routine
>  to whack a complete data file into where the allocation pointer
>  points and update the pointer [using a 16KB transfer buffer
>  on the reads]. 

DJGPP's startup code and low-level library functions already do all
that for you, and you cannot do the above yourself in a DJGPP program,
because you will most certainly create a conflict with DJGPP
internals.

For example, the startup code already enters protected mode, so your
code will not be able to enter it again.

Also, as I told you in a previous message, any protected-mode setup
that is not identical (or at least very close) to what the DJGPP's
startup code does will almost certainly confuse any DJGPP debugger,
including the one built into RHIDE.

So any such ``prefix'' will have to assume that it's already in
protected mode, and that memory allocation should be done via DPMI
functions or through malloc, and pick up from there.  Then and only
then will it stand a reasonable chance of being debugged by DJGPP
debuggers.

>  Would RHIDE's GDB type debugger be happy with this? it would
>  just follow the source across into filename.S which
>  contained ASM_MAIN ??

I think somebody said that NASM cannot yet generate debug info, so you
might need to use Gas (and hence the AT&T syntax) to get full debug
support in assembly code.

- Raw text -