Advantages and Disadvantages of Using HJWasm

[GoneFishing]

Again to Fatal error A1113: Too many errors issue when assembling simple.asm with GCC- debug-build of HJWasm.
By default error limit is set to 50 . I played with -e switch that changes the error limit to specified value.
298 was a last value when HJWasm terminated correctly.
299 and above lead to  Segmentation fault

Just FYI

[hutch--]

Sounds like it needs an error count limit that stops trying after a preset number. Old MASM stops at 100 from memory with a message something like "Error count exceeds 100".

[johnsa]

Using GCC Debug build my side:

Code Select Expand


D:\HJWasm\HJWasm2.13.1s\HJWasm2.13.1s>MinGW-w64D\hjwasm -c -win64 -Zp8 ..\..\simple.asm

HJWasm v2.13, Feb  1 2016, Masm-compatible assembler.
Portions Copyright (c) 1992-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.

..\..\simple.asm: 9364 lines, 2 passes, 96 ms, 0 warnings, 0 errors
43 items in symbol table, expected 43
max items in a line=1, lines with 0/1/<=5/<=10 items=7966/43/0/0,
2049 items in resw table, max items/line=7 [0=662 1=688 376 114 42 11 5 2]
invokation CATSTR=0 SUBSTR=0 SIZESTR=0 INSTR=0 EQU(text)=0
lines read(files)/processed in pass one: 9363 / 9364
invokations: PreprocessLine=9418/9266/9265, Tokenize=18591/0
memory used: 946 kB


[GoneFishing]

-win64 -Zp8 - still the same errors here
GCC/Linux issue?

Error limit seems to be zero-based : -e0 means it shows one error followed by  "Fatal error A1113: Too many errors" 

[johnsa]

I guess it must be a linux/gcc build problem..

I'm using

gcc (x86_64-posix-seh-rev0, Built by MinGW-W64 project) 5.3.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[GoneFishing]

gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04)

I'll try re-install GCC to the latest stable version

[johnsa]

The Travis CI is using 4.6.3..
Have you tried it's build ? (It's linked from the website).

[GoneFishing]

Yes, I did . It works ok .
I need debug build , compiled with GCC 5.x

From what I read GCC version 5.x introduces new standarts , switching to it from 4.x may crash my system

[johnsa]

Ok .. let me know how a 5.x debug build goes!

[jj2007]

So based on this, for a literal string value passed in as a macro argument:
2   Is an immediate (absolute/constant) value if set.
5   References no undefined symbols and there is no error, if set.

IMHO there is a reason why MASM returns zero for "Hello, I am a string".
opattr returns non-zero for many things:

eax
[ebx+n]
[ebp+n]
123
myqword
mybyte
local myrect

Do you see a pattern? With the exception of 123, they are all defined symbols. However, this looks different:

Code Select Expand

  opax 123
  opax eax
  opax someundefinedvar

Myarg=123 with o=36
Myarg=eax with o=48
Myarg=someundefinedvar with o=0

And guess what? Even the not so latest versions of HJWasm return zero for someundefinedvar 8)

Btw, from the viewpoint of an assembler, -dword ptr [ebx+20] is undefined, but it should not throw an error. There are many macros that check if a symbol is still undefined and therefore has to be created.

I am not trying to be difficult here, on the contrary, I am trying to help you. If you plan to promote HJWasm as a perfect Masm clone, it should really behave as if it was Masm. This also implies that there should be a command line switch "use features that go beyond MASM", but the default should be "exactly like Masm". Otherwise those who use HJWasm must instruct their community "it looks like MASM but ...", and for many people that is one step too much.

[johnsa]

So based on this, for a literal string value passed in as a macro argument:
2   Is an immediate (absolute/constant) value if set.
5   References no undefined symbols and there is no error, if set.

IMHO there is a reason why MASM returns zero for "Hello, I am a string".
opattr returns non-zero for many things:

eax
[ebx+n]
[ebp+n]
123
myqword
mybyte
local myrect

Do you see a pattern? With the exception of 123, they are all defined symbols. However, this looks different:

Code Select Expand

  opax 123
  opax eax
  opax someundefinedvar

Myarg=123 with o=36
Myarg=eax with o=48
Myarg=someundefinedvar with o=0

And guess what? Even the not so latest versions of HJWasm return zero for someundefinedvar 8)

Have you tried the latest version with the opattr change in ?

Btw, from the viewpoint of an assembler, -dword ptr [ebx+20] is undefined, but it should not throw an error. There are many macros that check if a symbol is still undefined and therefore has to be created.
I am not trying to be difficult here, on the contrary, I am trying to help you. If you plan to promote HJWasm as a perfect Masm clone, it should really behave as if it was Masm. This also implies that there should be a command line switch "use features that go beyond MASM", but the default should be "exactly like Masm". Otherwise those who use HJWasm must instruct their community "it looks like MASM but ...", and for many people that is one step too much.

I have this listed in our issues log, I just haven't got my head around it as yet..
As for hjwasm being a masm clone, i think moving forward that becomes more and more unreasonable.. I moved away from masm because it's stuck in the past and receiving very little attention and will become even less so in the future. masm for 64bit programming is basically a no-go as far as I'm concerned.. its dreadful..

My argument thus is:
If you're creating 32bit stuff, there is no reason NOT to just use masm.. if we can get "as far as possible" compatible operation with hjwasm/masm then that's great.. hence why i'd consider the above request.
If you're creating 64bit stuff I would hope that whatever we have bares little resemblance to masm because it's crippled and will remain so.

One day we will have to accept that masm (unless someone at MS suddenly gets all enthusiastic) is basically a dead-end product, apart from 32bit (which is also dead-end in itself).

[johnsa]

Code Select Expand


mov eax,-dword ptr [ebx]


Just to confirm, this doesn't assemble with ML 11:

error A2026:constant expected

[jj2007]

mov eax, -dword ptr [ebx] doesn't assemble with any assembler, and rightly so.

But ML doesn't stop the assembly with an error, it simply returns zero in opattr signalling that this funny argument requires further "translations". In short: opattr should never stop the assembly, unless that is your choice:

Code Select Expand

opax macro arg
local oa, tmp$
  oa = opattr arg
  if oa
tmp$ CATSTR <## ">, <arg>, <" in line >, %@Line, < is a valid argument ##>
% echo tmp$
  else
tmp$ CATSTR <## sorry, ">, <arg>, <" in line >, %@Line, < is NOT a valid argument ##>
% echo tmp$
.err ; <<<<<< you CAN throw an error, but you are not obliged to do so
  endif
ENDM

Assembly output window:

## "dword ptr [ebx]" in line 16 is a valid argument ##
## sorry, "-dword ptr [ebx]" in line 17 is NOT a valid argument ##
## sorry, ""HJWasm is a perfect MASM clone"" in line 18 is NOT a valid argument ##
## sorry, "HJWasm is a perfect MASM clone" in line 19 is NOT a valid argument ##

[johnsa]

mov eax, -dword ptr [ebx] doesn't assemble with any assembler, and rightly so.

But ML doesn't stop the assembly with an error, it simply returns zero in opattr signalling that this funny argument requires further "translations".

Ahhh okay.. now I think we're starting to get to being on the right page.. I was under the impression you were expecting something useful to come back from the expression evaluation of that and that is what I could not figure! :)

Have you checked opattr with a literal string and -Zg switch? I've tested that with hjwasm and ml and they seem to produce the same macro output via echo.

[hutch--]

Something that will need to be done in the future is to create a 64 bit library of procedures for HJWASM so that it is no longer dependent on VC runtime DLLs and libraries at the user end. The 64 bit mnemonics are very powerful and there are more registers available in all types so there should be some extremely fast code options available with a properly optimised 64 bit library of procedures. Its a different brain to creating an assembler but it will have much to do with the success of the assembler if there is a decent body of very fast code available for users to exploit. Don't be beguiled by claims that VC runtime libraries are the fastest you can use, when it comes to maths, string, image, video and a whole host of other categories, properly optimised hand coded procedures will kick ass just as it did in Win32.