HJWasm 2.31 release

[mineiro]

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).

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

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

Code Select Expand

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$

[mineiro]

I have done a test on windows, not sure if helps, while it cannot display fine on console but works fine on gui.

Code Select Expand

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

[johnsa]

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.

[hutch--]

 

Urrrrgh, when are we going to get a HASM release ?  :P

[nidud]

deleted

[nidud]

deleted

[johnsa]

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.

[jj2007]

have 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.

Code Select Expand

.if !rv(CreateWindowEx, ...)
  .if rv(MessageBox, 0, "Could not create that control. Exit?", "Fatal error:", MB_OKCANCEL)==IDOK
       exit
  .endif
.endif

[nidud]

deleted

[jj2007]

What exactly is your message here, nidud?

Let me guess:

Code Select Expand

.if !rv(CreateWindowEx, ...)

is incredibly old-fashioned for you. 21st century coders need to write

Code Select Expand

.if !CreateWindowEx(...)

... so that it looks more like real C++? Even if it won't work with anybody who uses obsolete assemblers?

[nidud]

deleted

[nidud]

deleted

[johnsa]

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

[johnsa]

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 ?

[nidud]

deleted