HJWasm 2.31 release

[johnsa]

looking into struct/sse ones those seem valid problems..

invoke19 once again however seems to be just a chance in implementation.. for exmaple it gives an error on line 21:

Code Select Expand


fast2 proc fastcall a1:dword, a2:word
mov eax,a1
add eax,a2        ;<---------- here
ret
fast2 endp


in jwasm that works because under fastcall it just makes every parameter a dword, we no longer do so a2 would be in dx not edx ..

[nidud]

deleted

[johnsa]

VARARG64 and VARAR642 work for with -bin / -coff or -win64 without errors, specifying no command line switches generates errors, but I would expect I think given it's 64bit windows specific code it should really only work under -win64 / or -bin .. not really  convinced that -coff should even work (although it seems to).

If I do:

hasm64/32 -c -coff *.asm in the m32lib folder I have no errors

INVOKE2 with -bin or -omf / 16bit is also fine, none of them are giving me General Failure ?

[nidud]

deleted

[johnsa]

Ahh ok, got you.. let me try include all those files into one place and see what happens.

[johnsa]

It appears to be related to this:

proc.c line 1685

    sym = SymSearch( name );

    if( Parse_Pass == PASS_1 ) {

on PASS_1, the symbol definitely exists, name == "fn1"
on second pass.. it's NULL..

It looks like somewhere there is a memory leak that is overwriting the symbol table entry.

EDIT:
I've cleaned up some entries in symbols.h and put an additional check for null on the sym there, that seems to get it running through the full file-set now without issue.
Will keep an eye on it.

[GoneFishing]

...
Created two new Linux samples, Lin64_2 and Lin64_3 showing off the SystemV calling support as well as the portability of the OO and macro library.
...

Hi, JOHNSA
Thanks for not forgetting about Linux side of the *ASM .
My question is based mainly on pure curiosity and not practical interest because I'm in AFK mode this year.
Is it possible to call LIBC functions ( on Linux 64bit  ) with INVOKE macro ? Could you , please, provide a small sample illustrating this technique ?

[johnsa]

...
Created two new Linux samples, Lin64_2 and Lin64_3 showing off the SystemV calling support as well as the portability of the OO and macro library.
...

Hi, JOHNSA
Thanks for not forgetting about Linux side of the *ASM .
My question is based mainly on pure curiosity and not practical interest because I'm in AFK mode this year.
Is it possible to call LIBC functions ( on Linux 64bit  ) with INVOKE macro ? Could you , please, provide a small sample illustrating this technique ?

Hi,

Yep it should be no problem, the Lin64_2 and Lin64_3 samples I've added are linked with LIBC and use malloc/free already (via the MEMALLOC and MEMFREE macros).. so yep, just mark them as SYSTEMV in the proto, and invoke away :) (64bit only of course..)

[GoneFishing]

I don't see MEMALLOC and MEMFREE  definitions in your new samples. I guess they are builtin macros ...
Anyway I had  luck with

invoke exit , 42

Now I have to printf  "Hello World" 
How should I prototype printf function ?
Sorry for silly question

[mineiro]

Code Select Expand

;--- "hello world" for 64-bit Linux, using SYSCALL and SYSVCALL convention.
;--- assemble: HJWasm -elf64 -Fo=Lin64_2.o Lin64_2.asm
;--- link:     gcc Lin64_2.o -o Lin64_2
;---           ld -o Lin64_2  -dynamic-linker /lib64/l4.so.2   /usr/lib/x86_64-linux-gnu/crt1.o   /usr/lib/x86_64-linux-gnu/crti.o   -lc Lin64_2.o   /usr/lib/x86_64-linux-gnu/crtn.o

puts proto systemv pchar:ptr
exit proto systemv status:dword

.data

string db "string",0

.code

main PROC SYSTEMV
    invoke puts, addr string
    invoke exit,0
main ENDP

end


[GoneFishing]

Thanks, mineiro

Nice sample . Do you have another one with PRINTF function?

[mineiro]

hello sir GoneFishing;
Well, no.
I have tried to insert vararg on proto but that's being refused. I'm looking to that now.

[GoneFishing]

Mineiro, please, don't call me "sir"
Yes, I had the same problem. Let's wait what JOHNSA say

[mineiro]

hello GoneFishing;
I was not able to use invoke on printf function, so I hand coded that.

Code Select Expand

;--- "hello world" for 64-bit Linux, using SYSCALL and SYSVCALL convention.
;--- assemble: HJWasm -elf64 -Fo=Lin64_2.o Lin64_2.asm
;--- link:     gcc Lin64_2.o -o Lin64_2
;---           ld -o Lin64_2  -dynamic-linker /lib64/l4.so.2   /usr/lib/x86_64-linux-gnu/crt1.o   /usr/lib/x86_64-linux-gnu/crti.o   -lc Lin64_2.o   /usr/lib/x86_64-linux-gnu/crtn.o
.x64
puts proto systemv pchar:ptr
exit proto systemv status:dword
printf proto systemv ;;;:ptr VARARG

.data
format db "%s %d",0
number db 42,0
string db "string",0

.code

main PROC SYSTEMV
    invoke puts, addr string
;    invoke printf, addr format, addr string, addr number
    lea rdx,number
    lea rsi,string
    lea rdi,format
    mov rax,0 ;<-printf function, 0 members on xmm registers
    call printf
    invoke exit,0
main ENDP

end
Printf function on linux look to register rax with how many xmm registers are being used, so I setup that with zero.

[GoneFishing]

Yes, I know about RAX.
It's an workaround but not the solution.

Here's my test piece

;. /hasm -elf64 -Fo=test.o test.asm
; gcc -o test test.o   -lc
; ./test ; echo $?

printf   PROTO SYSTEMV :VARARG
exit      PROTO SYSTEMV exitCode:QWORD

.data

mystring byte  "Hello, world!",0

.code

main PROC SYSTEMV
     invoke printf, offset mystring
     invoke exit, 42
     ret
main ENDP

end

I can assemble and link it without errors but executable results in Segmentation fault