NEW--ASM/C++ 32bit link

[b][red]This message was edited by xkgdiam at 2003-11-21 19:12:53[/red][/b][hr]
[code]
i use new on the topic cause i edit the first message to this
i have some functions in assembly and try to call them from c++
my assembly file user .386 directive to have acces on 32 bit registers

First, when i pass the assembly file in Bcc
$(BCC) -3 -ms -M -li -l3 -lc ccall32.cpp call32.asm
in compiles my asm as 16 bit although -3 option,
i solve this using TASM32 to make my asm obj, ok.

Second, here is asm function :
.386
pushStack ;macro so ebp point the 1st arg
mov eax,[ebp]
;;; mov dx,ax ;;;;;;;;;;;;;;
popStack ;pop ebp
_ret ;if(__LARGE__) retf , if(__SMALL__) ret
is there any command to get MSWord of eax to dx
so return a long ?

Third, why my BCC uses 16 bit registers althought i use option -3
that supports 386 instructions.
And finaly BCC always act like that (16bit) or my macros will
fail in some other linking ?
(in push stack macro i add ebp 2bytes for IP and 2bytes for CS
if a large program, also i add the bp or ebp space)








[/code]


Comments

  • Hello,
    Error messages given by an assembler often have the line number.
    If your editor doesn't clearly show the line number of the cursor,
    you'll have a hard time finding the errors untill you get another editor.
    *Warning* call32.ASM(2) Assuming segment is 32-bit
    So we're talking about line 2? as the source of the error which is:
    .386 (but this is a post, so only you know for sure what is on line #2 of call32.asm)
    Setting the assemblers output to .386 sets the address size for
    CALL, stack RET, etc at 32 and that is where the error lies? (your macros?)
    Another thought is: Nasm will allow creative coding & full control,
    where others demand you define severe limits and stay with in them.
    Does your assembler allow mixed codeing & addressing size? (16 & 32 bit) ?
    I'm not familuar with the assembler your using,
    so maybe others will offer further info to get you unstuck.
    Bitdog

  • As for getting EAX into DX:AX, it's quite simple:
    [code]
    rol eax,16 ;This instruction exchanges the MSW and LSW of EAX.
    mov dx,ax
    rol eax,16
    [/code]
    There might be a better way to do this, but that was the first thing that came to mind.

    Additionally, something I do when referencing params (mmm, not much :-/) is to use ESP such as:
    [code]
    ;function SignExtend(Byte : char) : integer; {Yes, this is for Pascal.}
    Byte equ 4
    SignExtend:
    movsx ax,byte [esp + Byte]
    retf 2
    [/code]

    Note that using ESP per instruction that uses it is usually one byte larger than if you used EBP (and some small timing constraint, too, I think) but it overall keeps the code smaller and faster when you include the pushing and popping of EBP as well as the move of ESP into EBP that would occur in alternate code.
  • [b][red]This message was edited by xkgdiam at 2003-11-22 14:36:4[/red][/b][hr]
    [code]
    to bitdog,
    i'm using the TASM / TASM32 assemblers
    this warning comes out when i obj my file with TASM,
    and refers to the following command in a macro
    ifdef __LARGE__
    .model large ;;*Warning* Assuming segment is 32-bit
    _ret equ retf
    _CSonStack equ 2
    else
    .model small;;*Warning* Assuming segment is 32-bit
    _ret equ ret
    _CSonStack equ 0
    endif
    and under TASM assembles wrong the following :
    push ebp ->TASM-> push bp
    mov eax,[ebp+0] ->TASM-> mov ax,[di+0]
    push eax ->TASM-> push ax
    pop ax ->TASM-> pop eax
    although .386 directive,under TASM32 no warnings,no erros
    ---------
    to blip,
    i think to use this also
    push eax
    pop ax
    pop dx

    About sp i have think that too, and maybe i will
    but when funtion returns control to c++ function
    before poke the return value (dx:ax or ax)
    it adds to sp the amount of bytes the args were
    Would the use of sp directly cause some problems ??

    Some thing more ,
    Using TASM32
    My_Code W32Dasm_output
    .386
    (...)
    in ax,dx ED -> in ax,dx
    in eax,dx 66ED -> in ax,dx

    Is my program compiled correctly ?


    [/code]



  • : i'm using the TASM / TASM32 assemblers

    [green]
    I'm not a Tasm man, you need Asmguru62 to answer your questions.
    He's a Tasm man, he hangs out at the Windows .asm board here at Programmers Heaven now a days.
    I could guess at a solution,
    your address size is wrong because your macro doesn't load the proper code.
    I would simplify it by removing the ifdef stuff
    and try straightcode untill you get something that works,
    then try the macro ifdef stuff.
    Then fix the macro, or fix the define that is suspose to cause
    the macro to assemble one code or the other. Your .386 line?
    Bitdog
    [/green]

  • [b][red]This message was edited by Moderator at 2003-11-25 11:59:52[/red][/b][hr]
    What is the purpose of these? IIRC, they're not legal.
    [code]
    _ret equ retf
    ;...
    _ret equ ret
    [/code]
    It looks like you have TASM assembling in 32-bit mode when you want 16-bit, or you're using a 16-bit disassembler when you need a 32-bit one (W32DASM should be 32-bit...). I don't see why IN EAX,DX is disassembled as IN AX,DX when its opcode clearly corresponds with the former as it would be in 16-bit mode.

    I think using ESP to reference parameters would cause as many problems as using (E)BP. The obvious differences are that the BP doesn't have to be pushed or popped unless you're using it for some reason (another free reg :)), but you must not allow the high word of it to become anything other than zero when running as 16-bit code. This reminds me of when I found that my Intel Celeron P][ had a bug (feature?) where it would use ESP for stack functions regardless of what mode it was in, causing a freeze in real mode if it was nonzero.


Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Categories