Advantages and Disadvantages of Using HJWasm

[habran]

I agree fully with you hutch-- :t
I suggest to do it as a team, everyone should get involved.
We can post it here for testing and improving until we are satisfied and tan add to the library.
You could create one thread for that here on masm forum.
JJ has got already plenty of them but he has to convert them to 64 bit, it is time for him to make that step forward like
Neil Armstrong 46 years ago ;)
Because I already have that avatar with Godfather I can propose a name to it: FASTLIB 8)

[habran]

We are planing to add HJWasm capability to process precompiled headers and hopefully capability to work directly with
.h files.
We were searching the net to find something useful to understand how to create them and read them but we couldn't find anything useful, what we already don't know :(
So, we would appreciate very much any info about it

[hutch--]

Being able to use the C++ headers would be a massive advantage but it would probably also be a massive undertaking, essentially writing a C compiler front end to convert the .H files into something that an assembler could use.

[habran]

Being able to use the C++ headers would be a massive advantage but it would probably also be a massive undertaking, essentially writing a C compiler front end to convert the .H files into something that an assembler could use.

You are right hutch--,

Being able to use the C++ headers would be a massive advantage but it would probably also be a massive undertaking, essentially writing a C compiler front end to convert the .H files into something that an assembler could use.

and you are right again
My plan is in the beginning to call Watcom(64) to create precompiled headers for the beginning until we create the preprocesor to do that job.
My first goal is to make HJWasm able to read precompiled headers, the rest is chickenshit

[jj2007]

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.

That's right, same output for the literal string. Not for the rest, though, and unfortunately it doesn't like this:

ife opattr SQWORD
   SQWORD equ QWORD   ; to make signed qwords available in MASM 6.15
endif

Same for SQWORD equ <QWORD> (both are OK for ML). Note that SQWORD is available in ML 8.0 but not earlier; meaning -Zg refers apparently to ML 6.15 (not 6.14, because then no MasmBasic code would assemble)

*** Assemble using hjwasm64 /c /coff -Zg /Fo "Opax" ***
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.

\masm32\MasmBasic\MasmBasic.inc(411) : Error A2209: Syntax error: equ QWORD
\masm32\MasmBasic\MasmBasic.inc(411): Included by
  Tmp_File.asm(1): Main line code
*** using MasmBasic version 01.02.2016 ***
UNKNOWN=0
0 is type 0 with size 4294967295
## "dword ptr [ebx]" in line 16 is a valid argument ##
Tmp_File.asm(17) : Error A2065: Constant expected
opax(1)[Tmp_File.asm]: Macro called from
  Tmp_File.asm(17): Main line code
## 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 ##
Tmp_File.asm: 20 lines, 1 passes, 172 ms, 0 warnings, 2 errors
*** Assembly Error ***

[TWell]

Here is Open Watcom 2 wcpp source as PellesC project.
I hope it helps someone.

[GoneFishing]

AFAIK Open Watcom ( even its latest non-official fork v2 ) can't produce 64 bit binaries.

Creating 64 bit version of OW standard library would be great . Full documentation and source code are already available.

... and of course I look forward to link a test app and 64 bit stdlib with  HJWLink   
 

[habran]

AFAIK Open Watcom ( even its latest non-official fork v2 ) can't produce 64 bit binaries.

Are you sure about that? I just downloaded source from latest non-official fork v2 because they said it can create 64 bit
I will play a little bit with it next few days to see what it can do 8)

[GoneFishing]

AFAIK Open Watcom ( even its latest non-official fork v2 ) can't produce 64 bit binaries.

Are you sure about that?

The definitive answer is No as I have not been able to find any documentation on changes they've made in v2
They provide both 32 and 64 bit binaries but can they compile 64 bit targets ? That is the question

[EDIT] OOPS ,sorry , it seems it supports win64 targets

[habran]

Here is Open Watcom 2 wcpp source as PellesC project.
I hope it helps someone.

Thanks TWell, I will see how it works :t

jj2007, I will leave opattr and -Zg to Johnsa to decide what next.
My question is do you want to make that step forward and translate some of your library (if not all) into 64 bit?
Get over MASM 6.14 ;)

[habran]

GoneFishing, next few days I will take time and try to build 64 bit HJWasm with Open Watcom and see what it produces

[GoneFishing]

OK
I downloaded v2 too . Trying to compile it 

[TWell]

This is V2 Fork of Open Watcom suite of compilers and tools

Bellow is list of main differences against Open Watcom 1.9

New 2-phase build system, OW can be build by platform native C/C++ compiler or by itself
Code generator properly initialize pointers by DLL symbol addresses
DOS version of tools now support long file names (LFN) if appropriate LFN driver is loaded by DOS
OW is ported to 64-bit hosts (WIN64, Linux X64)
Librarian support X64 CPU object modules and libraries
RDOS 32-bit C run-time compact memory model libraries are fixed
Resource compiler and Resource editors support WIN64 executables
OW text editor is now self containing, it can be used as standalone tool without any requirements for any additional files or configuration
Broken C++ compiler pre-compiled header template support is fixed
Many C++ compiler crashes are fixed
Debugger has no length limit for any used environment variable

[jj2007]

My question is do you want to make that step forward and translate some of your library (if not all) into 64 bit?

25,000+ lines of highly optimised code, based on teamwork in dozens of threads in the Laboratory? NO.

> Get over MASM 6.14 ;)
I've never used it.

[habran]

What is the point of having 25,000+ lines of highly optimised code if no one want to use it :icon_eek:
I wrote some highly optimised code on COMODORE64,
however, I don't think that it is now important, even though I enjoyed so much in writing it
I believe that you are probably an excellent programmer, however, you cling with your teeth on 32 bit, until you have the last tut left in your mouth
All you know about shearing is how to spell it ;)