Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.msdos.programmer > #1465

Re: XMS transfer troubles with Turbo C

Show all headers | View raw

Mateusz Viste  <mateusz.viste@localhost> wrote:
>That's what I did today - I removed my C operations on registers, and 
>replaced them with inline ASM. So far, thing didn't changed, but I am 
>not really sure what such thing mean:
>
>         call    [dword cs:XMSDriver]

Ah, yes, sorry, I should have caught that.  You know how I said you can't
safely change _DS because you can't be sure what code the compiler will
generate that will be dependent on the DS registers?  Well, you have to
be careful that when you change the value of the DS segment register in
assembly that none of your instructions after that implictly depend on
the old value of DS.

So why use the CS overide (the "cs:" part of the instuction), why not
just do this:

	call	[dword XMSDriver]

Well this instruction implicitly uses the DS register. It's the equivilent
of this instruction which makes the use of DS explicit.

	call	[dword ds:XMSDriver]

This instruction loads the DWORD at the address calculated by taking
the offset of the address where XMSDriver is located and adding to the
value of the DS segment.  The segment part of the address of XMSDriver
is doesn't form part of this caclulation.  That DWORD value is then
interpretted as a far pointer which is used to load CS and IP.

When you use a CS override instead of a DS override, it does the same
thing except that it adds the value of the CS segment to the offset
of XMSDriver.

Why does the assembly code do this? Well, hopefully it's obvious, it
does this because it changed the value of DS.  If XMSDriver was located
in the segment that DS normally points to then, it would no longer be
accessible through DS.  So the assembly code either assumes that CS =
DS, or the that the XMSDriver variable was defined in the code segment
rather than data segment.

You need to solve this problem the same way. Either find a segment
register that already happens to have the same value, or put your
equivilent of the XMSDriver variable in the code segment.  Since you're
probably not using the tiny memory model you can't assume CS = DS,
but you're probably using a memory model were SS = DS.  So using a SS
override ("ss:") should work.  

Alternatively you can put your XMSDriver variable in the code segment.
I believe this is how you would do it in Turbo C, but I can't easily
test it:

	void far * _cs XMSDriver;

>I also recompiled my program with OpenWatcom, and there, I have to use 
>such construct:
>
>         call    [dword ptr XMSDriver]
>
>there is an additional 'ptr' that I added, because otherwise the 
>compiler was complaining. By the way, is the above semantically the same 
>than this one?
>
>         call    dword ptr [XMSDriver]

They're probably equivilent but depends on the assembler and I'm not
familiar with the Watcom assembler.  I think TASM might treat them
differently in Ideal mode.

Note that you shouldn't actually need the use DWORD PTR cast with
OpenWatcom, the compiler and/or assembler should know the type and size
of XMSDriver and so pick the correct instruction. You need to the use the
"dword" operand size override with NASM because it doesn't use types,
and so doesn't know the size of XMSDriver, even if it was defined earlier
in the same assembly file.  It's default assumption if you don't use
"dword" is that XMSDriver is word sized, and so generates a near call
instead of far call.

					Ross Ridge

-- 
 l/  //	  Ross Ridge -- The Great HTMU
[oo][oo]  rridge@csclub.uwaterloo.ca
-()-/()/  http://www.csclub.uwaterloo.ca/~rridge/ 
 db  //	  

Back to comp.os.msdos.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

XMS transfer troubles with Turbo C Mateusz Viste <mateusz.viste@localhost> - 2014-07-24 19:18 +0200
  Re: XMS transfer troubles with Turbo C Johann Klammer <klammerj@NOSPAM.a1.net> - 2014-07-24 22:00 +0200
    Re: XMS transfer troubles with Turbo C Mateusz Viste <mateusz.viste@localhost> - 2014-07-25 08:12 +0200
  Re: XMS transfer troubles with Turbo C Ross Ridge <rridge@csclub.uwaterloo.ca> - 2014-07-25 15:54 -0400
    Re: XMS transfer troubles with Turbo C Mateusz Viste <mateusz.viste@localhost> - 2014-07-26 16:34 +0200
      Re: XMS transfer troubles with Turbo C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-07-26 13:21 -0400
        Re: XMS transfer troubles with Turbo C Mateusz Viste <mateusz.viste@localhost> - 2014-07-27 09:57 +0200
          Re: XMS transfer troubles with Turbo C Mateusz Viste <mateusz.viste@localhost> - 2014-07-27 10:38 +0200
            Re: XMS transfer troubles with Turbo C Mateusz Viste <mateusz.viste@localhost> - 2014-07-27 11:01 +0200
              Re: XMS transfer troubles with Turbo C Mateusz Viste <mateusz.viste@localhost> - 2014-07-27 11:20 +0200
                Re: XMS transfer troubles with Turbo C Mateusz Viste <mateusz.viste@localhost> - 2014-07-27 12:07 +0200
                Re: XMS transfer troubles with Turbo C Mateusz Viste <mateusz.viste@localhost> - 2014-07-27 12:41 +0200
                Re: XMS transfer troubles with Turbo C Mateusz Viste <mateusz.viste@localhost> - 2014-07-27 15:46 +0200
                Re: XMS transfer troubles with Turbo C Johann Klammer <klammerj@NOSPAM.a1.net> - 2014-07-27 16:39 +0200
                Re: XMS transfer troubles with Turbo C Mateusz Viste <mateusz.viste@localhost> - 2014-07-27 20:09 +0200
          Re: XMS transfer troubles with Turbo C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-07-27 12:32 -0400
            Re: XMS transfer troubles when AWEUTIL is loaded (exception 0D) Mateusz Viste <mateusz.viste@localhost> - 2014-07-27 20:23 +0200
      Re: XMS transfer troubles with Turbo C Ross Ridge <rridge@csclub.uwaterloo.ca> - 2014-07-27 12:25 -0400
        Re: XMS transfer troubles when AWEUTIL is loaded (exception 0D) Mateusz Viste <mateusz.viste@localhost> - 2014-07-27 20:05 +0200
          Re: XMS transfer troubles when AWEUTIL is loaded (exception 0D) "Alexei A. Frounze" <alexfrunews@gmail.com> - 2014-07-28 22:13 -0700
            Re: XMS transfer troubles when AWEUTIL is loaded (exception 0D) rugxulo@gmail.com - 2014-07-29 15:08 -0700
              Re: XMS transfer troubles when AWEUTIL is loaded (exception 0D) Mateusz Viste <mateusz.viste@localhost> - 2014-07-30 08:25 +0200
  Re: XMS transfer troubles Mateusz Viste <mateusz.viste@localhost> - 2014-07-28 21:10 +0200

csiph-web