2.31 version is up, packages on the site!
Changes:
Fixed a 32bit MS FASTCALL issue
Fixed encoding bug with VMOVQ.
Fixed VMOVSS/VMOVSD allowing 2 register form, when 3 registers are required for all-register mode and added error message for it.
Updated VECTORCALL, FASTCALL x64 to support 3 register VMOVSS/VMOVSD form if archAVX on, when generating PROC or INVOKE.
Optimised and improved FASTCALL handlers and completely redeveloped SYSTEMV calling convention implementation.
Fixed a potential memory corruption bug in the symbol table.
Added support for Intel MPX extensions, bnd0-3 registers and new instructions.
Added custom USES to OO Library method definitions
Added MEMALLOC and MEMFREE macros, which are now also used internally by the Macro Library.
These two macros will use HeapAlloc on Windows and malloc/free via libc on Linux/OSX.. making them portable.
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.
Update oo1 sample as well to show the customisable USES clause.
Cheers!
John
Quote from: johnsa on May 15, 2017, 07:32:11 PM
Fixed encoding bug with VMOVQ.
Fixed VMOVSS/VMOVSD allowing 2 register form, when 3 registers are required for all-register mode and added error message for it.
Why this instruction "vcvtps2pd ymm0,ymm1" compiles in JWASM but "Error A2049: Invalid instruction operands" in HJWASM/new name ?
It should be
vcvtps2pd ymm0,xmm1
it expands 4 floats from an XMM to 4 doubles in YMM.
So that shouldn't work as it was.
OR you can use 2x XMM registers and it'll convert 2 floats only.
Quote from: johnsa on May 15, 2017, 11:12:38 PM
It should be
vcvtps2pd ymm0,xmm1
it expands 4 floats from an XMM to 4 doubles in YMM.
So that shouldn't work as it was.
OR you can use 2x XMM registers and it'll convert 2 floats only.
JWASM encodes vcvtps2pd ymm0,ymm1 to vcvtps2pd ymm0,xmm1, this is the reason it does not produce error.
deleted
Quote from: aw27 on May 15, 2017, 11:41:56 PM
Quote from: johnsa on May 15, 2017, 11:12:38 PM
It should be
vcvtps2pd ymm0,xmm1
it expands 4 floats from an XMM to 4 doubles in YMM.
So that shouldn't work as it was.
OR you can use 2x XMM registers and it'll convert 2 floats only.
JWASM encodes vcvtps2pd ymm0,ymm1 to vcvtps2pd ymm0,xmm1, this is the reason it does not produce error.
Yep, but I think it's better to report the invalid instruction rather, so at least you know and can correct it. This was linked to a lot of other simd/avx instructions which jwasm didn't really check very well, some of which could have had some unintended side-effects like automatically assumimg xmm0 etc.
Hi nidud,
289: invoke foo,L"Unicode"
00007ff6a4a612d6 48 8D 0D 83 2D 00 00 lea rcx, ptr [rip+0x2d83] ;00007FF6A4A64060h
00007ff6a4a612dd E8 0E FE FF FF call 0x7ff6a4a610f0
0x00007FF6A4A64060 55 00 6e 00 69 00 63 00 6f 00 64 U.n.i.c.o.d
0x00007FF6A4A6406B 00 65 00 00 00 55 6e 69 63 6f 64 .e...Unicod
0x00007FF6A4A64076 65 00 00 00 00 00 00 00 00 00 00 e..........
built-in macro library is available to x64 only because there are plenty of macros for 32 bit
/* Process our built-in macro library to make it available to the rest of the source (x64 only) */
if (Parse_Pass == PASS_1 && Options.nomlib == FALSE && ModuleInfo.defOfssize == USE64) {
unsigned alist = ModuleInfo.list;
ModuleInfo.list = 0;
InitAutoMacros();
ModuleInfo.list = alist;
}
So after some discussion with JJ2007 it appears that supporting string literals in invoke may create some unforseen compatibility issues.
for example:
invoke myFunc, "a"
traditionally would pass 'a' as a byte to the proc, same applies for "ab", "abcd" .. which are now being picked up as string literals.
What we do have still is support for using dw in the .data sections to create wide character string data and we have @CSTR, @WSTR built-in macros (in 64bit).
Option a) rollback the support for literal strings (keep the dw support and rely on using the macros).. for 32bit the classic CStr/WStr macros can be used which rely on the dw support too.
Option b) change the handling to only convert the quoted argument to a string literal if the procedure parameter's type is PTR.. however this might not play well with any existing function that doesn't use PTR but simply qword or dword as the argument type.
I'm inclined to go with option a but I'd like everyone's thoughts first.
EDIT: another option might be to introduce some new delimiter for the literals, will probably require tokenizer update but might be a better option ?
something like:
invoke myFunc, "a", {literal text}, 10 ; unicode
invoke myFunc, "b", <literal text>, 10 ; ascii
deleted
Quote from: johnsa on May 16, 2017, 06:30:30 AMOption a) rollback the support for literal strings (keep the dw support and rely on using the macros).. for 32bit the classic CStr/WStr macros can be used which rely on the dw support too.
While testing the new HJWasm release, I got an unexpected build error. Only by accident did I find this problem: I rarely use the explicit form je
short label; and only because I used the "short", the assembler choked. With ten years of assembler experience, it took me several hours to find out what exactly had happened. The trick was in the end to copy the whole code section from Olly's disassembly, and to compare both versions in a kind of blink comparator. Then I finally saw that AsmC and ML pushed 55h while HJWasm pushed an offset, with a longer encoding that made the short jump exceed its limit.
This is not a minor incompatibility. This is a major recipe for disaster, for the introduction of bugs that are extremely difficult to chase. My bug, for example, did not cause any damage so far but only by sheer accident... and it might have created big problems at any moment in time.
P.S.: Please stick to HJWasm - not because of my name, I am just an active user, but both Japheth and John have invested a lot of effort; they deserve a little "J" ;)
Quote from: nidud on May 16, 2017, 06:35:26 AM
invoke strchr,edi,"c"
Maybe an option or a switch?
Or a little extra?
invoke strchr, edi, $"This is a string"
But then, invoke strchr, edi, chr$("This is a string") has always been part of Masm32. Simple and unambiguous... same for Chr$() (http://www.webalice.it/jj2006/MasmBasicQuickReference.htm#Mb1251), of course.
string db 13,10,"hello, world.",13,10
wstring dw "A wide string",0
.code
main proc c
local dwWritten:dword
local hConsole:dword
invoke GetStdHandle, STD_OUTPUT_HANDLE
mov hConsole, eax
invoke WriteConsoleA, hConsole, <ASCII\n\n>, 5, addr dwWritten, 0
invoke WriteConsoleW, hConsole, {Unicode}, 7, addr dwWritten, 0
invoke WriteConsoleW, hConsole, addr wstring, 13, addr dwWritten, 0
invoke WriteConsoleA, hConsole, addr string, sizeof string, addr dwWritten, 0
I have this working as an option ? Can't think offhand of anything this would interfere with historically? as the <> and {} are limited in scope to the context of the INVOKE parameters
However that causes issues now when fed via a macro to invoke as the <> and {} are stripped out... hmm
Really, there is no lack of options that do work without breaking existing code...
include \masm32\MasmBasic\MasmBasic.inc
.code
main proc c
local dwWritten:dword
local hConsole:dword
invoke GetStdHandle, STD_OUTPUT_HANDLE
mov hConsole, eax
invoke WriteConsoleA, hConsole, cfm$("ASCII\n\n"), 9, addr dwWritten, 0
invoke WriteConsoleW, hConsole, wChr$("Unicode "), 8, addr dwWritten, 0
lea ecx, dwWritten
invoke WriteConsoleW, hConsole, uChr$("текст"), 5, ecx, 0
ret
main endp
Init
call main
EndOfCode
deleted
deleted
I think will be good if assembler understands unicode text files instead of only ascii text files, this way you don't touch on this problem.
If user like to use unicode strings on source code so will save as unicode file, if like to deal with ascii files will save as ascii text. Text editor will do these transformation to you (us).
;--- "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
stdout equ 1
SYS_WRITE equ 1
SYS_EXIT equ 60
WriteToConsole PROTO SYSTEMV pString:PTR, strLen:DWORD, outHandle:DWORD
.data
aMsg db 10,"This source file was saved using utf8 encode!",10,0
bMsg db "An utf8 string: 䌣吲敃ሴ癔蝥⍅⍧㑖",10,0
.code
main PROC SYSTEMV
invoke WriteToConsole, ADDR aMsg, sizeof aMsg, stdout
invoke WriteToConsole, ADDR bMsg, sizeof bMsg, stdout
invoke WriteToConsole,"é⍅ሴ⍅\n",2+3+3+3+1,stdout
mov eax, SYS_EXIT
syscall
ret
main ENDP
WriteToConsole PROC SYSTEMV pString:PTR, strLen:DWORD, outHandle:DWORD
LOCAL handle:DWORD
mov handle, outHandle ; this is allowed as outHandle evaluates as a register operand.
mov edx, strLen
mov rsi, pString
mov edi, handle
mov eax, SYS_WRITE
syscall
ret
WriteToConsole ENDP
end
mineiro@assembly:~/Documentos/hasm/hasm231_linux64/Samples$ ./hasm -elf64 -Fo=Lin64_2.o Lin64_2.asm
Hasm v2.31, May 15 2017, Masm-compatible assembler.
Portions Copyright (c) 1992-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
Lin64_2.asm: 41 lines, 3 passes, 1947 ms, 0 warnings, 0 errors
mineiro@assembly:~/Documentos/hasm/hasm231_linux64/Samples$ gcc Lin64_2.o -o lin64_2
mineiro@assembly:~/Documentos/hasm/hasm231_linux64/Samples$ ./lin64_2
This source file was saved using utf8 encode!
An utf8 string: 䌣吲敃ሴ癔蝥⍅⍧㑖
é⍅ሴ⍅
mineiro@assembly:~/Documentos/hasm/hasm231_linux64/Samples$
I have done a test on windows, not sure if helps, while it cannot display fine on console but works fine on gui.
include masm32rt.inc
.data?
houtput dd ?
nada dd ?
.data
UTF8_BOM db 0efh,0bbh,0bfh
;UNICODE_BOM db 0ffh,0feh
utf8 db "accents: áéíóúçã"
.code
start:
invoke GetStdHandle,STD_OUTPUT_HANDLE
mov houtput,eax
;invoke SetConsoleOutputCP,CP_UTF8
invoke WriteFile,houtput,addr UTF8_BOM,sizeof UTF8_BOM,addr nada,0
invoke WriteFile,houtput,addr utf8,sizeof utf8,addr nada,0
invoke ExitProcess,0
end start
Save code above as test.asm on notepad using utf8 encode.
Open hex editor and remove bom (first 3 bytes). Save. Assemble as console and redirect output to text file.
c:\test > i.txt
c:\notepad i.txt
My thoughts are this:
for standard INVOKE, we rollback the literal string support entirely, so you'd use CSTR/WSTR.
To support literal strings and char-style data it would be best to follow Nidud's lead here I think and have a more HLL style way of calling procs which uses that format, that way you get the functionality without breaking any legacy calls/invokes.
:biggrin:
Urrrrgh, when are we going to get a HASM release ? :P
deleted
deleted
Ok,
I've updated Git and the packages on the site to Hasm 2.32
I've added in the initial utf8 BOM check (linked to to Twells suggestions and Miniero's request)
I've also rolled back the literal string support completely from invoke and kept only dw support in data sections. Documents and samples updated accordingly.
This should at least keep everyone "happy'ish" while we look at a better option.
Quote from: johnsa on May 16, 2017, 08:13:10 PMhave a more HLL style way of calling procs
Don't forget it's a macro assembler. Not every feature needs to be built into the assembler. The rv macro, for example, has been around for ages.
.if !rv(CreateWindowEx, ...)
.if rv(MessageBox, 0, "Could not create that control. Exit?", "Fatal error:", MB_OKCANCEL)==IDOK
exit
.endif
.endif
deleted
What exactly is your message here, nidud?
Let me guess:
.if !rv(CreateWindowEx, ...)
is incredibly old-fashioned for you. 21st century coders need to write
.if !CreateWindowEx(...)
... so that it looks more like real C++? Even if it won't work with anybody who uses obsolete assemblers?
deleted
deleted
Ok,
Fixing the vex encoded forms : vldmxcsr m32
etc..
FPO32, INVOK648, INVOK649 fixed.
648+649 warn about missing endprolog as they have no RET, which should really be there under our enforced PROC FRAME.
INVOK13 fixed, no errors or general failure this side.
Thanks! :t
John
I'm not sure how much I trust all of the regression tests tbh, I think they need cleaning up .. for example:
src\PUSH.ASM(24) : Error A2089: Cannot access label through segment registers: m16
src\PUSH.ASM(25) : Error A2089: Cannot access label through segment registers: m16s
These errors are produced by Jwasm 2.12, so they're not new in HJWasm/Hasm..
The source assembles fines as -bin, but this error above is produce with -coff
I'm not too sure if they're actually even valid statements under -coff anyway ?
deleted
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:
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 ..
deleted
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 ?
deleted
Ahh ok, got you.. let me try include all those files into one place and see what happens.
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.
Quote from: johnsa on May 15, 2017, 07:32:11 PM
...
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 ?
Quote from: GoneFishing on May 17, 2017, 10:42:04 PM
Quote from: johnsa on May 15, 2017, 07:32:11 PM
...
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..)
I don't see MEMALLOC and MEMFREE definitions in your new samples. I guess they are builtin macros ...
Anyway I had luck with
Quoteinvoke exit , 42
Now I have to printf "Hello World" :biggrin:
How should I prototype printf function ?
Sorry for silly question
;--- "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
Thanks, mineiro
Nice sample . Do you have another one with PRINTF function?
hello sir GoneFishing;
Well, no.
I have tried to insert vararg on proto but that's being refused. I'm looking to that now.
Mineiro, please, don't call me "sir"
Yes, I had the same problem. Let's wait what JOHNSA say
hello GoneFishing;
I was not able to use invoke on printf function, so I hand coded that.
;--- "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.
Yes, I know about RAX.
It's an workaround but not the solution.
Here's my test piece
Quote
;. /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
Not silly at all! We just spent a huge amount of time getting a proper SystemV 64bit ABI support in, so apart from my trivial Linux n00b testing it'll be great to have someone actually use/try it out!
For printf :
printf PROTO SYSTEMV fmtStr:PTR, opt:VARARG
.data
bMsg db "Hello from me %s %d",10,0
cMsg db "..ME..",0
.code
invoke printf, ADDR bMsg, ADDR cMsg, 10
Please wait 10 min before trying and use Hasm v2.33 (which I'm busy updating now.. It has a lot of fixes, but one especially relevant here is allowing ADDR to be used in VARARGS) :)
Thanks, JOHNSA :t
I'll wait for new version of HASM
2.33 is up (for Linux only so-far, others will follow this evening).
That sorts out the printf issue, let me know how that works for you!
Cheers
John
:t
Works fine with my test piece:
Quote
;. /hasm -elf64 -Fo=test.o test.asm
; gcc -o test test.o -lc
; ./test ; echo $?
printf PROTO SYSTEMV fmtStr:PTR, opt:VARARG
exit PROTO SYSTEMV exitCode:DWORD ; QWORD was incorrect , edited.
.data
mystring db "Hello, world!",10,0
.code
main PROC SYSTEMV
invoke printf, ADDR mystring
invoke exit, 42
ret
main ENDP
end
Looks like you've done a big amount of work in developing HJWASM , now HASM .
I'll need some time to learn changes and new features.
Cheers
I think exit still takes a 32bit int, but in that case making it a qword won't break anything
That's right . I edited that line in exit proto
hello GoneFishing;
On that code that generates segmentation fault insert 'mov rax,0' before call printf function.
hello johnsa;
Thanks for updated hasm.
@mineiro:
nice find
@johnsa :
printf function is very helpful in testing SYSTEMV ABI implementeion: we can gradually increase number of arguments and change its type. I've just performed quick test with floating point argument and got "Illegal instruction" response" ( without crashing )
That's all for today, now I must go
Same here GoneFishing;
This error happens here because my computer is old, only support SSE 2 instructions.
objdump -M intel -d test
4005ea: c5 f9 6e c0 vmovd xmm0,eax
If you're machine doesn't support AVX, use the command line switch -archSSE
When ever HASM generates any code (for prologue/epilogue/invoke/macro library etc) it will respect that switch and use the corresponding opcodes/instructions in the generated code.
The mov eax,0 shouldn't be necessary to add manually for vararg as hasm adds it automatically as either mov eax,count or xor,eax,eax if there are no used vector registers in the varargs.
In terms of gradually expanding and testing the combinations of SystemV ABI I'm attaching my test-case for it so you can see all the ones we've already gone through :)
PS, just like with Vectorcall support on Windows Hasm has built-in data types for __m128, __m256, __m512 and then new union initialisation syntax.
So these types along with normal xmm/ymm/zmm registers can be passed to PROCs under SystemV as per the ABI.
There are a bunch of examples of this in the attached source.
New union initializer allows you to specify which sub-type to use as opposed to only allowing the first, very helpful when working with these vector types for SIMD.
align 16
myVec __m128.i32 { <0,1,2,3> }
align 32
myVec2 __m256.i32 { <0,1,2,3,4,5,6,7> }
hello johnsa
working fine here with that switch option -archSSE :t
thank you
-edit-
I have faced some problems johnsa, follow testcase code, disasm and output
;hasm -archSSE -elf64 -Fo=test.o test.asm
;gcc test.o -o test
.x64
exit proto systemv status:dword
printf PROTO SYSTEMV pformat:PTR, arg:VARARG
.data
teste dq 123.456
number dq 23.78
veja db "%f %f",10,0
format db "%s %d %f",10,0
string db "string",0
.code
main PROC
movd xmm1,qword ptr [number] ;movq don't works!
movd xmm0,qword ptr [teste]
mov rax,2
lea rdi,veja
call printf
invoke printf, addr format, addr string, 42, 123.456
invoke exit,0
ret
main ENDP
end
$ ./test
123.456000 23.780000
string 42 0.000000
0000000000400580 <main>:
400580: 48 83 ec 08 sub rsp,0x8
400584: 66 48 0f 6e 0d cb 0a movq xmm1,QWORD PTR [rip+0x200acb] # 601058 <number>
40058b: 20 00
40058d: 66 48 0f 6e 05 ba 0a movq xmm0,QWORD PTR [rip+0x200aba] # 601050 <teste>
400594: 20 00
400596: 48 c7 c0 02 00 00 00 mov rax,0x2
40059d: 48 8d 3d bc 0a 20 00 lea rdi,[rip+0x200abc] # 601060 <veja>
4005a4: e8 a7 fe ff ff call 400450 <printf@plt>
4005a9: 48 8d 3d b7 0a 20 00 lea rdi,[rip+0x200ab7] # 601067 <format>
4005b0: 48 8d 35 ba 0a 20 00 lea rsi,[rip+0x200aba] # 601071 <string>
4005b7: 48 c7 c2 2a 00 00 00 mov rdx,0x2a
4005be: b8 79 e9 f6 42 mov eax,0x42f6e979
4005c3: 66 0f 6e c0 movd xmm0,eax
4005c7: b8 01 00 00 00 mov eax,0x1
4005cc: e8 7f fe ff ff call 400450 <printf@plt>
4005d1: 33 ff xor edi,edi
4005d3: e8 a8 fe ff ff call 400480 <exit@plt>
4005d8: 48 83 c4 08 add rsp,0x8
4005dc: c3 ret
disasm looks right ? Wonder why it's printing a 0.00 though
Ok.. think I found the issue..
C99 standard specifies that ALL float arguments to a variadic are promoted to double.
So..
to conform, %f actually needs a double input so you need to invoke like :
invoke printf, addr format, addr string, 42, real8 ptr 123.456
however.. for some reason real8 ptr isn't working on Linux build, it works perfectly when assembling on Windows however. I will investigate.
thanks johnsa;
a command line to disassemble files on linux is:
objdump -M intel -d executable
Saying this because you have c language skills, so you can see whats happening on background based on c language.
This is not a priority to me ok, if you have other issues resolve them first.
again thank you.
Right it's all fixed up, please grab 2.33 dated 18th of May and you can now do the following:
.data
bMsg db "Hello from me %s %d",10,0
cMsg db "..ME..",0
format db "%s %d %f",10,0
string db "string",0
aNum REAL8 123.456
.code
main PROC SYSTEMV
MEMALLOC(200)
MEMFREE(rax)
invoke WriteToConsole, CSTR("Hello, world!"), 13, stdout
invoke printf, addr format, addr string, 42, real8 ptr 123.456
invoke printf, ADDR bMsg, ADDR cMsg, 10
invoke printf, addr format, addr string, 42, aNum
thank you johnsa;
just to feedback you, I have tested hasm with agner fog file PMCTestB64.asm to measure code and works fine.
Excellent! glad to hear it :t
Hi JOHNSA,
Back to your test case from Reply #54 .
Does nix1 test app exit normally for you ? No SEGFAULT ?
No it doesn't run properly, there is some nonsense code in there reading from bad memory like [rax], it was just an example of the types of invoke/parameter combinations that i was using to verify the invoke generation.
I've put Lin64_2 and Lin64_3 in the package as samples and there are 1 or 2 system v fixes ready too for 2.35 which will be out very shortly (like in a day or so).
Thanks, JOHNSA
It makes sense now. Anyway your UASM is far far ahead of my expectations and needs .
deleted
Good find,
It sounds like a fair 5% gain when running across a set of files! I'll move the check into ProcessFile then.