5

Here's a test procedure from a program I'm working on, I pass in some parm's via the stack, one of which is a pointer. When I try to change the value of the dereferenced pointer, the variable isn't updated. 

_testProc proc
    push bp                             ;Save base pointer to stack
    mov bp, sp                          ;Set new base pointer
    sub sp, 4                           ;Allocate stack space for locals
    pusha                               ;Save registers to stack

    mov di, [bp + 08]                   ;Parm 3 - ptr to variable

    mov word ptr [di], 10   ; <---- Doesn't work. di contains an address, 
                            ;       but what it points at doesn't get updated

    popa                                ;Restore registers from stack
    mov sp, bp                          ;Remove local vars by restoring sp
    pop bp                              ;Restore base pointer from stack
    ret 6                               ;Return and also clean up parms on stack
_testProc endp
Mark
  • 157
  • 1
  • 9

2 Answers2

3

The 8086 produces and address by combining the contents of a segment register and an index register; I show that as [SR,IR].

Your update via register di is updating a location defined by [DS,DI]; mov instructions without any special prefix default to using the DS register. If you got the address DI as an offset for some other segment (ES? SS?) then you are in effect combining the wrong registers to hit the address you desire.

Your mistake is in not being clear about what the conventions are for passing a "pointer" to your routine. What you've define assume a relative offset from DS.

Ira Baxter
  • 93,541
  • 22
  • 172
  • 341
  • I checked the DS and that's right where my data is, so this is clearly my problem. However I'm not quite sure what the correct way to handle this is? In this case the pointer was pointing to a local variable from the calling procedure that was on the stack... But what if this same procedure was called and passed a pointer to a variable in the data segment? How can I handle both cases? – Mark Dec 02 '12 at 07:55
  • @Mark: I guess either you need to have DS equal to SS, or use far pointers for all data. It's probably worth looking at the different "memory models" (tiny,small, large,...) of old DOS compilers. – ninjalj Dec 02 '12 at 11:41
  • @Mark: If your data is in the stack, then your pointer is stack segment relative, and you need to write "mov word ptr SS:[di], 10" to get the location modified. If your procedure is *always* intended to modify data in the stack segment, then this is a bug fix. If your procedure must be able to modify any location anywhere (e.g., relative to any segment), then you need to pass the segment register to the procedure (e.g., in the ES:) register, and write "mov word ptr ES:[di], 10". – Ira Baxter Dec 02 '12 at 14:56
  • @ninjalj Thanks, one of the next things I'm supposed to be looking at is other memory models. Maybe I've just gotten a bit ahead of my self. – Mark Dec 02 '12 at 15:30
  • @Ira Thanks again, I hadn't thought of using the ES which is much cleaner than what I had come up with and think this might be the fix for this case. Ultimately I think you're correct that I need to use a more strict calling convention, if I were to say all pointer arguments point back to the stack this becomes easy. – Mark Dec 02 '12 at 15:38
2

The very best thing you can do is to abandon 16-bit segmented code as soon as you can! :)

Failing that, there's "far data" and a "far pointer" to point to it. Your "proc" doesn't say if it's near or far - I assume near (or Parm3 probably isn't where you think it is on the stack... since the far return address is 4 bytes). If the variable you intend to alter is on the stack, you're in for some more complication. mov word ptr ss:[di], 10 at least. If you need to handle either a local or static variable, I think you're going to need a far pointer (4 bytes, segment and offset) to find it.

What first came to my mind is that you say you're trying to change the value of a dereferenced pointer, you don't "dereference" it (as I understand it). Try mov di, [di] after you get the value off the stack. Easy to try, anyway. :)

If all else fails, show us the calling code. (and get into 32-bit code as soon as you can!)

Frank Kotler
  • 1,462
  • 1
  • 8
  • 4
  • Thanks, unfortunately I'm locked into to 16bit code for this. However I'm curious as to how switching to 32bit helps? With 32bit code I'm sure segments are still used, so isn't this still an issue? – Mark Dec 02 '12 at 15:23
  • @Mark: in 32-bit OSes protected mode and a flat memory model is usually used. Protected mode means that segment registers point to segment descriptors in special tables (the GDT and the LDT), which describe how to translate addresses with segments (logical/virtual addresses) to addresses without segments (linear addresses). Flat memory model means that all segments contain all the memory, by setting the segment base to 0 and the segment limit to 4Gb. So. e.g: CS and DS point to the same memory, and only permissions are different. – ninjalj Dec 02 '12 at 16:27
  • Yes, there are segment registers in 32 mode, but mostly they aren't used. See my answer: http://stackoverflow.com/a/10810340/120163 – Ira Baxter Dec 02 '12 at 20:54