I made this new topic because hutch-- got bored with the last one ;)
Anyway, when we are already on this topic:
DISADVANTAGES: NONE OUT OF 100%
ADVANTAGES :THE REST
I fixed the bug with special registers which was hiding in parser.c line 2079
Try to find another one, that one was to easy :biggrin:
Quote from: habran on January 31, 2016, 03:43:58 PM
DISADVANTAGES: NONE OUT OF 100%...
Try to find another one, that one was to easy :biggrin:
DISADVANTAGES: NOT COMPATIBLE WITH MASM
Quote from: habran on January 30, 2016, 12:16:10 AM
jj2007,
opax -DWORD PTR[rbx]; << << assembles fine with MASM
It shouldn't because it is wrong
JWasm see that '-' as error because it does better job than MASM
If you were an assembler and come to such a statement wouldn't you complain ;)
I know for sure that you would screem :biggrin:
include \masm32\include\masm32rt.inc
opax macro arg
Local oa, tmp$
oa = opattr arg
tmp$ CATSTR <TheArg=>, <arg>, < with opattr=>, %oa
% echo tmp$
; TheArg="a string" with opattr=36 ; HJWasm64
; TheArg="a string" with opattr=36 ; ML 10.0
ENDM
.code
start:
opax "a string" ; <<<<<<<<< 0 with ML, 36 with HJWasm
opax DWORD PTR [ebx]
opax -DWORD PTR [ebx] ; <<<< assembles fine with MASM
print "ok"
exit
end start
;)
If this is all you have to throw on HJWasm I am glad that this part is not compatible 8)
Why would anybody write -DWORD PTR [ebx] unless under global influence of alcohol or some worse drug? :biggrin:
I can assure you that I would be able to make it work in HJWasm but I am not gonna do it :bgrin:
If you remember scene from "Groundhog Day" when Phil says to Ned: "I would love to have a coffee with you but I am not gonna do it" :biggrin:
Quote from: habran on January 31, 2016, 07:07:05 PMWhy would anybody write -DWORD PTR [ebx]
Because you
can do it with the Microsoft macro assembler (MASM) 8)
(and I do actually have a meaningful use for that one...)
I understand that you are tired, but have a look at the wrong opattr for "a string", though, which HJWasm flags as "immediate", while ML gives a zero, meaning "undefined". That might really break some non-JJ code 8)
Quote from: habran on January 31, 2016, 07:07:05 PM
If this is all you have to throw on HJWasm I am glad that this part is not compatible 8)
Why would anybody write -DWORD PTR [ebx] unless under global influence of alcohol or some worse drug? :biggrin:
I can assure you that I would be able to make it work in HJWasm but I am not gonna do it :bgrin:
If you remember scene from "Groundhog Day" when Phil says to Ned: "I would love to have a coffee with you but I am not gonna do it" :biggrin:
What is the expected outcome of -dword ptr [ebx] ? (what do you use it for?) not being nosey.. just curious as i've never encountered it before :)
mov dword ptr [ebx],0
this code is ambiguous - you don't know whether the operand is byte, word, or dword sized
mov [ebx],0
Quote from: dedndave on January 31, 2016, 09:45:22 PM
mov dword ptr [ebx],0
this code is ambiguous - you don't know whether the operand is byte, word, or dword sized
mov [ebx],0
i know why you'd use a dword ptr with an immediate or type override obviously.
i mean, what is the purpose of the unary minus..
mov -dword ptr [ebx],0
mov eax,-dword ptr [ebx]
etc?
:biggrin:
> got bored with the last one
Nah, I was having trouble with the page depth.
Quote from: johnsa on January 31, 2016, 10:03:32 PMwhat is the purpose of the unary minus..
The concrete case here is a macro:
GuiWarp ccurve, ul warpX:warpY, ur -warpX:warpY, ll -warpX:-warpY, lr warpX:-warpY
ccurve is a Gdi+ graphics object (a "closed curve" in this case), ul means upper left, ur upper right etc, and warpX and warpY are, well, parameters for the warp function.
You can see it in action with the attachment: use arrow left/right/up/down to see the fungus changing its shape (right-click to let it "float").
Here, warpX and warpY are variables defined via SetGlobals (http://www.webalice.it/jj2006/MasmBasicQuickReference.htm#Mb1015), i.e. [ebx+someoffset].
The one-liner above looks like this under the hood:
0108371D ³. 8B43 99 mov eax, [ebx-67]
01083720 ³. 8B53 9D mov edx, [ebx-63]
01083723 ³. F7DA neg edx
01083725 ³. C1E2 10 shl edx, 10
01083728 ³. 66:0BD0 or dx, ax
0108372B ³. 52 push edx ; Úarglr
0108372C ³. 8B43 99 mov eax, [ebx-67] ; ³
0108372F ³. F7D8 neg eax ; ³
01083731 ³. 8B53 9D mov edx, [ebx-63] ; ³
01083734 ³. F7DA neg edx ; ³
01083736 ³. C1E2 10 shl edx, 10 ; ³
01083739 ³. 66:0BD0 or dx, ax ; ³
0108373C ³. 52 push edx ; ³argll
0108373D ³. 8B43 99 mov eax, [ebx-67] ; ³
01083740 ³. F7D8 neg eax ; ³
01083742 ³. 8B53 9D mov edx, [ebx-63] ; ³
01083745 ³. C1E2 10 shl edx, 10 ; ³
01083748 ³. 66:0BD0 or dx, ax ; ³
0108374B ³. 52 push edx ; ³argur
0108374C ³. 8B43 99 mov eax, [ebx-67] ; ³
0108374F ³. 8B53 9D mov edx, [ebx-63] ; ³
01083752 ³. C1E2 10 shl edx, 10 ; ³
01083755 ³. 66:0BD0 or dx, ax ; ³
01083758 ³. 52 push edx ; ³argul
01083759 ³. 6A 0B push 0B ; ³inx = 11.
0108375B ³. E8 C4090000 call MbWarp ; ÀMbWarpOf course, it is a matter of taste if you prefer "pure" assembler or a macro. But IMH experience design and development of such applications proceeds faster with macros, and the code is more readable to those who are willing to read the macro's manual entry.
Btw the macro works with ML and HJWasm, but the workaround for making it compatible was non-trivial.
Hi,
I started looking into the opattr issue today and I don't believe it would be right for us to change this.. From what I can see , 36 is the correct value and 0 is wrong.
From the masm reference for OPATTR (bit definitions):
OPATTR/.TYPE Return Value
Bit(s) Meaning
0 References a label in the code segment if set.
1 References a memory variable or relocatable data object if set.
2 Is an immediate (absolute/constant) value if set.
3 Uses direct memory addressing if set.
4 Is a register name, if set.
5 References no undefined symbols and there is no error, if set.
6 Is an SS: relative reference, if set.
7 References an external name.
8-10
000 - no language type
001 - C/C++ language type
010 - SYSCALL language type
011 - STDCALL language type
100 - Pascal language type
101 - FORTRAN language type
110 - BASIC language type
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.
Bit's 2 and 5 should be set. 5 at the very least if you debate the immediate/constant'ness of the literal string.. neither being 0. Bits 2+5 = 36.
That's true
... but HJWasm has -Zg switch :
Quote-Zg Generated code is to exactly match Masm's one
From JWASM's manual:
QuoteOption -Zg: Masm-compatible Code Generation
Option -Zg makes JWasm try an exact copy of Masm's code generation, which results in the following changes:
the default prologue for procedures will use
add [e]sp, - localsize
instead of
sub [e]sp, localsize.
the default epilogue for procedures will almost always prefer to generate opcode LEAVE if possible.
expressions
<reg> == 0 and <reg> != 0
will generate code
or <reg>,<reg>
instead of
cmp <reg>,0.
if invoke must extend an argument's size from word to dword, register eax remains unchanged.
the segment value of FAR externals will always be assumed unknown, no matter whether the external is defined inside or outside of a segment block. Thus those labels are excluded from "far call optimization".
I think it would not be that hard to preserve MASM compatibility , at least through the special command line switch
Quote from: GoneFishing on February 01, 2016, 09:03:30 PM
That's true
... but HJWasm has -Zg switch :
Quote-Zg Generated code is to exactly match Masm's one
From JWASM's manual:
QuoteOption -Zg: Masm-compatible Code Generation
Option -Zg makes JWasm try an exact copy of Masm's code generation, which results in the following changes:
the default prologue for procedures will use
add [e]sp, - localsize
instead of
sub [e]sp, localsize.
the default epilogue for procedures will almost always prefer to generate opcode LEAVE if possible.
expressions
<reg> == 0 and <reg> != 0
will generate code
or <reg>,<reg>
instead of
cmp <reg>,0.
if invoke must extend an argument's size from word to dword, register eax remains unchanged.
the segment value of FAR externals will always be assumed unknown, no matter whether the external is defined inside or outside of a segment block. Thus those labels are excluded from "far call optimization".
I think it would not be that hard to preserve MASM compatibility , at least through the special command line switch
Ok.. your wish is our command :)
-Zg will now force opattr=0 for literal string and 36 otherwise.
Please test and let me know, source committed to github.
GCC DEBUG=1:
gcc -c -IH -D__UNIX__ -DDEBUG_OUT -g -o GccUnixD/symbols.o symbols.c
symbols.c: In function 'DumpSymbol':
symbols.c:807:5: warning: format '%p' expects argument of type 'void *', but argument 5 has type 'union <anonymous>' [-Wformat=]
printf( "%-12s %16" I64_SPEC "X %02X %8p %c %8p %s\n", type, value, sym->mem_type, dir->e, sym->ispublic ? 'X' : ' ', (void*)sym->name, (void*)sym->name );
^
symbols.c:807:5: warning: format '%s' expects argument of type 'char *', but argument 8 has type 'void *' [-Wformat=]
Quote from: johnsa on February 01, 2016, 09:47:37 PM
...
Ok.. your wish is our command :)
...
Sounds great! Still it's not my wish and not a wish at all ... It's an idea
Not sure if I can generate my own ideas I only translate already existing ideas to you ;)
Ok, that last one in symbols.c should be fixed now.
GCC DEBUG=1: no warnings :t
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
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".
Using GCC Debug build my side:
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
-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"
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.
gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04)
I'll try re-install GCC to the latest stable version
The Travis CI is using 4.6.3..
Have you tried it's build ? (It's linked from the website).
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
Ok .. let me know how a 5.x debug build goes!
Quote from: johnsa on February 01, 2016, 08:42:48 PMSo 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:
opax 123
opax eax
opax someundefinedvarMyarg=123 with o=36
Myarg=eax with o=48
Myarg=someundefinedvar with
o=0And 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.
Quote from: jj2007 on February 02, 2016, 01:11:12 AM
Quote from: johnsa on February 01, 2016, 08:42:48 PMSo 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:
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 ?
Quote
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).
mov eax,-dword ptr [ebx]
Just to confirm, this doesn't assemble with ML 11:
error A2026:constant expected
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:
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 ##
Quote from: jj2007 on February 02, 2016, 02:58:29 AM
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.
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.
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)
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 :greenclp:
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.
Quote from: hutch-- on February 02, 2016, 03:23:40 PM
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--,
Quote from: hutch-- on February 02, 2016, 03:23:40 PM
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 :biggrin:
Quote from: johnsa on February 02, 2016, 03:04:00 AMHave 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
endifSame 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 ***
Here is Open Watcom 2 wcpp source as PellesC project.
I hope it helps someone.
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 :biggrin:
Quote from: GoneFishing on February 02, 2016, 07:40:05 PM
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)
Quote from: habran on February 02, 2016, 08:27:32 PM
Quote from: GoneFishing on February 02, 2016, 07:40:05 PM
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
Quote from: TWell on February 02, 2016, 06:19:01 PM
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 ;)
GoneFishing, next few days I will take time and try to build 64 bit HJWasm with Open Watcom and see what it produces
OK
I downloaded v2 too . Trying to compile it :biggrin:
QuoteThis 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
Quote from: habran on February 02, 2016, 08:41:40 PMMy 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.
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 :eusa_boohoo:
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 :biggrin:
All you know about shearing is how to spell it ;)
Quote from: GoneFishing on February 02, 2016, 08:55:49 PM
OK
I downloaded v2 too . Trying to compile it :biggrin:
Please let me know if you do :biggrin:
Quote from: habran on February 02, 2016, 10:44:50 PM
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 :eusa_boohoo:
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 :biggrin:
Hey, why are you trying to insult me? I am just showing you where HJWasm is still incompatible to ML. If you are not interested, let me know. And why the hell should I switch to 64 bits? Zero advantage, a thousand headaches.
Btw I don't really
need HJWasm, for developing I am using AsmC because it's twice as fast, then I check the final version with ML 6.15 and ML 10.0. And I try to remain compatible with JWasm and HJWasm.
QuoteAll you know about shearing is how to spell it ;)
You probably meant
sharing :P
Quote from: habran on February 02, 2016, 11:03:43 PM
Quote from: GoneFishing on February 02, 2016, 08:55:49 PM
OK
I downloaded v2 too . Trying to compile it :biggrin:
Please let me know if you do :biggrin:
Sure
No luck till now ...
Quote from: jj2007 on February 02, 2016, 04:33:15 PM
Quote from: johnsa on February 02, 2016, 03:04:00 AMHave 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 ***
SQWORD being a reserved word cannot be redefined (hence the error). While this is not MASM 6.15 compatible it is MASM 8 compatible which exhibits exactly the same behaviour, the IFE will skip due to SQWORD being defined, and if you try to force the equ the assembly will error.
I've changed it to use switch -Zne instead of -Zg (seems more appropriate) and to work around the fact that i cannot (without immense effort) remove sqword as a reserved word based on a switch, i've specifically excluded SQWORD from the parser change to 0 when using -Zne , so SQWORD will still return 36 and the IFE block will bypass.
This means the source will assemble and be correct, but it's not ML 6.x compatible as that would opattr to 0 AND SQWORD wouldn't exist as a reserved word...
That said.. there is a limit to how much of this sort of "backwards" compatibility we can apply ..
I think the intention of JWASM being completely masm compatible was noble, but it seems a lot of things have never been 100% masm compatible.. I would hope to achieve 98% compatible :) and keep it at that.. especially for 32bit as I don't forsee any changes in that area.. it's not where things are moving.. My only concerns would be things which work in JWASM but no longer in HJWASM, those should rightly work as before without very good reason for changing.
I've uploaded these changes to the site and git. JJ give that a try and see if that allows your block to assemble now.
JJ I was right, you know how to spell it :t I don't.
My intention was not to insult you, I wanted to shake you out of your buts, because I thought we are friends
Now I know that I was barking up to wrong tree.
I enjoy sharing because I am generous person.
I promise you I will not bother you any more 8)
>GoneFishing, I was expecting that they will include project for building 64 bit watcom, however I couldn't find it :(
HABRAN,
OW build system is so much sophisticated that no one simple mortal can build it :biggrin:
I already have experience of compiling OW 1.9 on Linux but v2 is even more complicated .
All is based on makefiles of custom format .
On Linux one is supposed to specify if he wants to use GCC or OW toolchain to compile first binaries :
wmake and builder . After they are built , BUILDER utility does the rest of job :
Quotebuilder build
All this stuff is done in batch mode ...
Save your nerves - don't touch it , at least today ;)
GoneFishing, you are correct, I will let you sweat, and see if you can solve the puzzle, I believe in you :t
I'll try my best
Ok for the compile of simple.asm (win10 64 bits),stay incorrect instructions at run
No other problem (forget FRAME)
The dumpbin (sdk tool ) show the errors
dumpbin /DISASM simple.exe
VMPSADBW ymm1, ymm2,m256, 0ah
vpbroadcastb xmm1, xmm2 ;<<<<<<<<<<<<<<<<<<<<<< error here
0000000140001045: C4 E3 6D 42 0D B1 vmpsadbw ymm1,ymm2,ymmword ptr [140019000h],0Ah
7F 01 00 0A
000000014000104F: 62 ;<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
0000000140001050: F2 7D 08 bnd jge 000000014000105B
0000000140001053: 78 CA js 000000014000101F
Quote from: ToutEnMasm on February 03, 2016, 02:16:03 AM
The dumpbin (sdk tool ) show the errors
dumpbin /DISASM simple.exe
VMPSADBW ymm1, ymm2,m256, 0ah
vpbroadcastb xmm1, xmm2 ;<<<<<<<<<<<<<<<<<<<<<< error here
0000000140001045: C4 E3 6D 42 0D B1 vmpsadbw ymm1,ymm2,ymmword ptr [140019000h],0Ah
7F 01 00 0A
000000014000104F: 62 ;<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
0000000140001050: F2 7D 08 bnd jge 000000014000105B
0000000140001053: 78 CA js 000000014000101F
I doubt dumpbin has any understanding of AVX512 as yet, the only thing which is going to give you realistic output would be OBJCONV.
Is simple.asm assembling ok and then generating error at runtime or are you getting an assemble time error?
I have the Windows sdk 10 and i use only his tools.
the dumpbin give the same results than the windbg for 64 bits.
I have an "Illegal Instruction" at run AND dumpbin failed to disasm the instruction
wrong instructions
;----------- VMOVHPD xmm21, xmm1, [rcx]
; -------- vpbroadcastb xmm1, xmm2
; ----------------- VMOVHPD [rcx],xmm22
xmm21 isn't a valid register under normal conditions...
that would only apply in AVX512 code where you now have 32 registers..
Habran: what about only enabling AVX512 extensions via a new option, which would also speed up the assembly time?
.mmx
.xmm
.zmm ;<-- we add this one?
vpbroadcastb xmm1, xmm2 SHOULD work.. but it's not encoding correctly, have logged as a bug.
I will check on these issues today.
HABRAN,
I've compiled OW v2 . All targets were built which took > 3 Gb of my disk space
Standard lib modules were not merged , I'll do it tomorrow
Quote./bwcc386 -?
Open Watcom C x86 32-bit Optimizing Compiler
Version 2.0 beta Feb 2 2016 19:43:57 (64-bit)
Copyright (c) 2002-2016 The Open Watcom Contributors. All Rights Reserved.
Portions Copyright (c) 1984-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
I noticed that there're no 64 bit targets in LIBC folder. This makes me suspect that I was right about 32-bit nature of v2 .
Precompiled binaries can be found here (http://sourceforge.net/projects/openwatcom/files/current-build/)
Quote from: johnsa on February 02, 2016, 11:45:43 PM
ife opattr SQWORD
SQWORD equ QWORD ; to make signed qwords available in MASM 6.15
endif
I've changed it to use switch -Zne instead of -Zg (seems more appropriate) and to work around the fact that i cannot (without immense effort) remove sqword as a reserved word based on a switch, i've specifically excluded SQWORD from the parser change to 0 when using -Zne , so SQWORD will still return 36 and the IFE block will bypass.
This means the source will assemble and be correct, but it's not ML 6.x compatible as that would opattr to 0 AND SQWORD wouldn't exist as a reserved word...
...
I've uploaded these changes to the site and git. JJ give that a try and see if that allows your block to assemble now.
With the exception of -dword ptr [ebx], it assembles now. Option -Zne (meaning what?) introduces another problem, though: immediates return zero for opattr.
I'll have a look at immediates returning 0.
I believe -Zne is "strict masm compatibility" , from Jwasm command line options so it seems more logical to use for this than -Zg which is generated code should match masm's.
GoneFishing, doing good job :t
Don't give up, they said that OW is able to create x64
I installed 64 bit on my laptop from that link yesterday, I hope that it was build with OW ::)
At the moment I am busy fixing some bugs in HJWasm, so I will relay on you for x64 build
Cheers!
Quote from: habran on February 03, 2016, 08:33:49 AM
..
Don't give up, they said that OW is able to create x64
I installed 64 bit on my laptop from that link yesterday, I hope that it was build with OW ::)
...
There's a possible misunderstanding here . OW v2 itself can be compiled to 64 bit with MSVC on Windows and maybe (!!!) GCC on Linux . From available prebuilt binaries we see that there's no Linux x64 installer . Most likely that GCC can't compile OW standard lib ( and that's true , I tried it with OW 1.9 ) .
Moreover I don't see specific x64 command line switches neither in WCC386 nor in WLINK .
Again , maybe I'm wrong in my guess
[EDIT] All OW v2 compiled binaries are 64 bit .
Simple test was compiled and linked as 32 bit:
#include<stdio.h>
int main()
{
printf("Hello from OW v2 !\n");
return 0;
}
Bad news :(
Did you check ntx64 folder in \open-watcom-v2-master\distrib\ow ?
ntx64 folders are for x64 makefiles?
Yes, it's there for creating of 64 bit installer .
distrib = distribution
Quote from: habran on February 03, 2016, 08:01:27 PM
Bad news :(
...
At the same time it's extremely good news.
That means Japheth was the first who made this big step forward and pushed obsolete OW toolchain ( not all of it, really, but the most significant tools - assembler and linker) to the big new world
It is ridicules, creating 64 bit tolls to build 32 bit code :dazzled:
I'm not sure if this is the right thread to ask this question in.
I'm taking a course in x86 (MASM) assembly at my university. It seems the students will be using Visual Studio on Windows. I'm wondering if the differences between HJWasm and MASM are large enough that I should avoid using HJWasm (on linux 64 bit)? If I were to follow my textbook (Kip Irvine - Assembly Language for x86 processors) and university coursework am I likely to run into trouble while trying to use HJWasm?