Author Topic: 32-bit static libraries with 64-bit asm  (Read 7919 times)

raymond

  • Member
  • **
  • Posts: 234
    • Raymond's page
32-bit static libraries with 64-bit asm
« on: September 11, 2013, 07:57:51 AM »
I`ve been toying with the idea of starting to use 64-bit assembly with Goasm. However, I can`t find any specific information on the following subject:
 
The 32-bit static libraries are not designed to handle the 64-bit parameters which seem to be essential when calling functions in 64-bit asm.

Is my assumption correct and all those libraries become useless, or is there any workaround to still be able to use such libraries?
Whenever you assume something, you risk being wrong half the time.
http://www.ray.masmcode.com/

dedndave

  • Member
  • *****
  • Posts: 8823
  • Still using Abacus 2.0
    • DednDave
Re: 32-bit static libraries with 64-bit asm
« Reply #1 on: September 11, 2013, 11:18:41 AM »
hi Ray - good to see you   :t

i am not a 64-bit GoAsm guy - lol
but, i saw your question unanswered, so i took a look

from what i can see....
http://donkeysstable.com/
if you go to the Headers page, it says...
Quote
Version 2.0 of the header project marks the beginning of WIN64 support.

Yuri

  • Member
  • **
  • Posts: 175
Re: 32-bit static libraries with 64-bit asm
« Reply #2 on: September 11, 2013, 01:03:16 PM »
Yes, in x64 the calling convention is different, so you need two different versions of a static library — one for x86 and another for x64. But that is not true for source code, it can be "switchable", i.e. you can build x86 and x64 binary code from the same source.

raymond

  • Member
  • **
  • Posts: 234
    • Raymond's page
Re: 32-bit static libraries with 64-bit asm
« Reply #3 on: September 14, 2013, 06:08:17 AM »
I`m starting to get somewhat frustrated with GoAsm. Without any decent help file, it took me hours to find out how to eventually correct some of the reported "errors" (such as, for example, how to properly define jump labels).

I`m trying to rewrite a short simple 32-bit program to 64-bit to compute the results of a complex algo (using a lot of 64-bit numbers), and then display the final result in a console along with the timing. Now I get the following error message which I can`t understand and haven`t been able to find a cure for it.

Quote
Error!
The backwards jump for this named re-usable label seems to go beyond the prior code label or beyond the stack FRAME:-
jb  .nextone

And, here`s the code it doesn`t seem to like:
Code: [Select]
.code

start:
      ARG offset freq
      invoke QueryPerformanceFrequency
      ARG offset counter
      invoke QueryPerformanceCounter

      xor   rbx,rbx    ;initialize some of the registers
      xor   rsi,rsi
      mov   rdi,1
      mov   [gend],rdi
      mov   r8,rdi
      mov   r9,rdi
      mov   r10,rdi
      mov   r11,rdi
      mov   r13,rdi
      mov   r15,rdi

.nextn                ;top of the recursion
      inc   Q[n]
      cmp   Q[n],1000000
      jb    .nextone
      jmp   .finish
.nextone
    ......

Initially, I had "jae  .finish" (and there was no nextone label) and the error message was then referencing the "finish" label. That`s when I tried the short jump for curiosity, and got the similar result.

First, it`s not a backward jump, and secondly I don`t use a FRAME (I don`t need one unless it`s an absolute necessity with Goasm even for console programs). Does anyone have an explanation for such an error message and possibly a cure to prevent it (and possibly get an .obj file assembled)?
Whenever you assume something, you risk being wrong half the time.
http://www.ray.masmcode.com/

dedndave

  • Member
  • *****
  • Posts: 8823
  • Still using Abacus 2.0
    • DednDave
Re: 32-bit static libraries with 64-bit asm
« Reply #4 on: September 14, 2013, 06:46:58 AM »
i think GoAsm uses:
"<" for short backward
"<<" for near backward
">" for short forward
">>" for near forward

Code: [Select]
jae >.finish
give it a try   :P

raymond

  • Member
  • **
  • Posts: 234
    • Raymond's page
Re: 32-bit static libraries with 64-bit asm
« Reply #5 on: September 14, 2013, 10:26:53 AM »
Thanks Dave. This did solve those nasty error messages.

But, I thought that it was the duty of any half-decent assembler to determine whether jumps should be coded as short or near to produce minimal code. And according to Jeremy`s own words, his design was based on the principle that it would result in an assembler which always produces the minimum size code and which has a clear and obvious syntax! What if the coder is too lazy to estimate jump ranges and codes ALL jumps as near?
Whenever you assume something, you risk being wrong half the time.
http://www.ray.masmcode.com/

dedndave

  • Member
  • *****
  • Posts: 8823
  • Still using Abacus 2.0
    • DednDave
Re: 32-bit static libraries with 64-bit asm
« Reply #6 on: September 14, 2013, 11:44:57 AM »
i haven't gotten that far, Ray   :P
i have more learning to do with 32-bit masm before i try anything new

Yuri

  • Member
  • **
  • Posts: 175
Re: 32-bit static libraries with 64-bit asm
« Reply #7 on: September 14, 2013, 01:28:13 PM »
Without any decent help file
But GoAsm does have a decent help file, and it contains an explanation of how various jumps are actually coded.

raymond

  • Member
  • **
  • Posts: 234
    • Raymond's page
Re: 32-bit static libraries with 64-bit asm
« Reply #8 on: September 16, 2013, 07:13:05 AM »
Without any decent help file
But GoAsm does have a decent help file, and it contains an explanation of how various jumps are actually coded.

My apology to Jeremy. I simply was not looking in the right place. Writing that assembler and the help file must have taken months of hard work, and is worth high marks. However, the more I look at it, the more frustrated I get. His intent to produce a syntax which is clear and obvious was not fully achieved in my opinion. I will leave it at that without further comments unless requested to do so.

The one positive note is that it can assemble and link 64-bit apps. And I have finally succeeded in converting my 32-bit algo to use 64-bit integers. The result was a reduction of the timing from 45 ms to 35 ms on my Intel Core i7 2.67GHz processor. However,for a still unknown reason, the timing was increased from 75 ms to 150 ms on my HP laptop equipped with an AMD E1-1200 running at 1.40GHz.

The only explanation I can think of at this time is that although the laptop was initially loaded with Windows8, my son somehow modified it such that it would simulate Windows7 desktop with its "Start" icon (so that it would be more familiar to me). This was a gift from him while I was being hospitalized.
Whenever you assume something, you risk being wrong half the time.
http://www.ray.masmcode.com/

dedndave

  • Member
  • *****
  • Posts: 8823
  • Still using Abacus 2.0
    • DednDave
Re: 32-bit static libraries with 64-bit asm
« Reply #9 on: September 16, 2013, 07:26:43 AM »
hope you are feeling better, Ray   :t

Yuri

  • Member
  • **
  • Posts: 175
Re: 32-bit static libraries with 64-bit asm
« Reply #10 on: September 16, 2013, 02:11:56 PM »
His intent to produce a syntax which is clear and obvious was not fully achieved in my opinion. I will leave it at that without further comments unless requested to do so.
Personally I would like to read your comments. The only thing I can say right now is any syntax takes time to get familiar with and used to. When I moved from C to GoAsm, I had a hard time learning how to use jumps for what I had previously done with if/else. But now using jumps looks like a more natural way to me.

The only explanation I can think of at this time is that although the laptop was initially loaded with Windows8, my son somehow modified it such that it would simulate Windows7 desktop with its "Start" icon (so that it would be more familiar to me).
I suspect you are running Windows 8.1 now, an update where they brought back the Start button.

dedndave

  • Member
  • *****
  • Posts: 8823
  • Still using Abacus 2.0
    • DednDave
Re: 32-bit static libraries with 64-bit asm
« Reply #11 on: September 16, 2013, 10:31:05 PM »
JwAsm is more Masm-like
you have to realize that GoAsm is not Masm   :P

raymond

  • Member
  • **
  • Posts: 234
    • Raymond's page
Re: 32-bit static libraries with 64-bit asm
« Reply #12 on: September 20, 2013, 01:38:09 PM »
Quote
Personally I would like to read your comments.
Here are a few of my frustrations.

1: Console window
Both Goasm and Golink are assembled as console apps according to the documentation. Both terminate by creating by its own console window which is most probably used to display error or success messages. However their appearance on the screen is so brief (a few ms) that it is impossible to view those messages. It should have been easy to add a few more instruction to keep that console window open until the user presses a key before terminating the programs. Why force the user to open his own console window to view those important messages when the console window has already been created.

(Another solution which is not mentioned in the documentation is to add the PAUSE instruction at the end of each batch file.)

2: Square brackets
When I had a look at NASM many, many, many years ago, it was forcing the use of square brackets around a memory variable to mean its content and, without brackets, to mean its memory address. In Goasm, using a memory variable without brackets has no use except to generate an error message. You still have to decorate it with some other prefix (OFFSET or ADDR) to get its address. Why force the use of brackets to get the variable`s value?  In basic algebra, a+b means the addition of the value of variable "a" and the value of variable "b".

I thus totally disagree with the main reason for the Goasm choice, i.e. "So when looking at assembler code, without knowing the syntax of the assembler concerned, you can never be really sure what MOV EAX,lParam does." The primary person to look at that code is the programmer himself and he had better be familiar with the syntax.
 
If the same reasoning had been used for other "novelties" in Goasm, they might never have seen the light of day, never being really sure of what they accomplish without knowing the syntax.

3: Jumps, direction, short vs near
The programmer is assumed to be familiar with the number of hex opcode bytes generated by each instruction whenever he specifies a forward jump as short. Might as well code every forward jump as near to avoid possible error messages.

4: Labels
Unique, re-usable, scoped, unscoped, ... ; looks like TYPE settings in C.
All these allowed variants of labels may have their utility on occasion but may lead to more confusion for the programmer, specially with the re-usable ones. And, for somebody else looking at the source code without knowing the syntax, he might never be really sure what JNZ XYZ does after seeing that label a few times already before and after this instruction.

Quote
I suspect you are running Windows 8.1 now, an update where they brought back the Start button.
This computer was purchased last May before the advent of Windows8.1. Unless MS included Windows8.1 as one of its updates (which I doubt), I would still have the original version. My Windows edition is still shown as Windows8.
Whenever you assume something, you risk being wrong half the time.
http://www.ray.masmcode.com/