Hi folks,
I'd like to introduce here JWasm hybrid I renamed to HJWasm
There are some new feature built in:
2 new flugs EQUAL and BELOW,
which can be handy with UCOMISS, UCOMISD, VUCOMISS, VUCOMISD instructions
4 new AVX2 instructions: VPGATHERDD, VPGATHERQD, VPGATHERDQ, VPGATHERQQ
added also VCMPxxPD, VCMPxxPS, VCMPxxSD, VCMPxxPD, VCMPxxSS
I have added in this version data definition directive 'DO' data for XMMWORD, 'DY' data for YMMWORD and 'DZ' for ZMMWORD
you have to change in your sources and includes (windows.inc line 12948 )dy to _dy
however I would prefer dx_ and dy_
MOUSEINPUT STRUCT
_dx DWORD ?
_dy DWORD ? ;windows.inc line 12948
mouseData DWORD ?
dwFlags DWORD ?
time DWORD ?
dwExtraInfo DWORD ?
MOUSEINPUT ENDS
I have included a source code with examples how they could be used
included also the HJWasm targets for the Visual Studio
This is still in development so please let me know if you encounter some bugs :biggrin:
Hi Habran,
great job. Is that the newest version? Should I use this version for compiling to other OS?
Gunther
Thanks Gunther :biggrin:
This is a new version, I don't know if you can use it without sources for other OS-es
I will post sources after little bit of testing
Hi habran!
I take the 32. There is some problems with ObjAsm32 that don't exist before. Surely Biterider understand better what happen.
Have You modified the nesting limits?
HJWasm v2.12pre, Jul 7 2015, Masm-compatible assembler.
Portions Copyright (c) 1992-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
STRING TYPE: ANSI
D:\masm32\Include\Windows.inc(12948) : Error A2209: Syntax error:
D:\masm32\Include\Windows.inc(12948): Included by
SysSetup(42)[Model.inc]: Macro called from
Demo02.asm(20): Main line code
D:\masm32\Include\Windows.inc(19071) : Error A2209: Syntax error:
D:\masm32\Include\Windows.inc(19071): Included by
SysSetup(42)[Model.inc]: Macro called from
Demo02.asm(20): Main line code
D:\masm32\ObjAsm32\Code\Macros\System.inc(788) : Error A2151: Unexpected literal found in expression: ¼c
D:\masm32\ObjAsm32\Code\Macros\System.inc(788): Included by
SysSetup(45)[Model.inc]: Macro called from
Demo02.asm(20): Main line code
D:\masm32\ObjAsm32\Code\Macros\System.inc(788) : Error A2082: Must be in segment block
D:\masm32\ObjAsm32\Code\Macros\System.inc(788): Included by
SysSetup(45)[Model.inc]: Macro called from
Demo02.asm(20): Main line code
D:\masm32\ObjAsm32\Code\Macros\System.inc(788) : Error A2209: Syntax error: @
D:\masm32\ObjAsm32\Code\Macros\System.inc(788): Included by
SysSetup(45)[Model.inc]: Macro called from
Demo02.asm(20): Main line code
D:\masm32\ObjAsm32\Code\Macros\System.inc(788) : Error A2082: Must be in segment block
D:\masm32\ObjAsm32\Code\Macros\System.inc(788): Included by
SysSetup(45)[Model.inc]: Macro called from
Demo02.asm(20): Main line code
D:\masm32\ObjAsm32\Code\Macros\System.inc(788) : Error A2209: Syntax error: @
D:\masm32\ObjAsm32\Code\Macros\System.inc(788): Included by
SysSetup(45)[Model.inc]: Macro called from
Demo02.asm(20): Main line code
D:\masm32\ObjAsm32\Code\Macros\System.inc(788) : Error A2082: Must be in segment block
D:\masm32\ObjAsm32\Code\Macros\System.inc(788): Included by
SysSetup(45)[Model.inc]: Macro called from
Demo02.asm(20): Main line code
D:\masm32\ObjAsm32\Code\Macros\System.inc(788) : Error A2209: Syntax error: @
D:\masm32\ObjAsm32\Code\Macros\System.inc(788): Included by
SysSetup(45)[Model.inc]: Macro called from
Demo02.asm(20): Main line code
D:\masm32\ObjAsm32\Code\Macros\System.inc(788) : Error A2082: Must be in segment block
D:\masm32\ObjAsm32\Code\Macros\System.inc(788): Included by
SysSetup(45)[Model.inc]: Macro called from
Demo02.asm(20): Main line code
D:\masm32\ObjAsm32\Code\Macros\System.inc(788) : Error A2209: Syntax error: @
D:\masm32\ObjAsm32\Code\Macros\System.inc(788): Included by
SysSetup(45)[Model.inc]: Macro called from
Demo02.asm(20): Main line code
D:\masm32\ObjAsm32\Code\Macros\System.inc(788) : Error A2082: Must be in segment block
D:\masm32\ObjAsm32\Code\Macros\System.inc(788): Included by
SysSetup(45)[Model.inc]: Macro called from
Demo02.asm(20): Main line code
D:\masm32\ObjAsm32\Code\Macros\System.inc(788) : Error A2209: Syntax error: @
D:\masm32\ObjAsm32\Code\Macros\System.inc(788): Included by
SysSetup(45)[Model.inc]: Macro called from
Demo02.asm(20): Main line code
D:\masm32\ObjAsm32\Code\Macros\System.inc(788) : Error A2082: Must be in segment block
D:\masm32\ObjAsm32\Code\Macros\System.inc(788): Included by
SysSetup(45)[Model.inc]: Macro called from
Demo02.asm(20): Main line code
D:\masm32\ObjAsm32\Code\Macros\System.inc(788) : Error A2082: Must be in segment block
D:\masm32\ObjAsm32\Code\Macros\System.inc(788): Included by
SysSetup(45)[Model.inc]: Macro called from
Demo02.asm(20): Main line code
D:\masm32\ObjAsm32\Code\Macros\System.inc(797) : Error A2082: Must be in segment block
D:\masm32\ObjAsm32\Code\Macros\System.inc(797): Included by
SysSetup(45)[Model.inc]: Macro called from
Demo02.asm(20): Main line code
D:\masm32\ObjAsm32\Code\Macros\System.inc(803) : Error A2082: Must be in segment block
D:\masm32\ObjAsm32\Code\Macros\System.inc(803): Included by
SysSetup(45)[Model.inc]: Macro called from
Demo02.asm(20): Main line code
D:\masm32\ObjAsm32\Code\Macros\System.inc(803) : Error A2082: Must be in segment block
D:\masm32\ObjAsm32\Code\Macros\System.inc(803): Included by
SysSetup(45)[Model.inc]: Macro called from
Demo02.asm(20): Main line code
D:\masm32\ObjAsm32\Code\Macros\System.inc(810) : Error A2162: Unmatched macro nesting
D:\masm32\ObjAsm32\Code\Macros\System.inc(810): Included by
SysSetup(45)[Model.inc]: Macro called from
Demo02.asm(20): Main line code
DEBUG MODE : ACTIVE -> WND
STACKGUARD : ACTIVE
SUPPORT FOR: OOP
SUPPORT FOR: WINDOWS
Inheritance path: Primer
Inheritance path: Primer,DesLUT
Inheritance path: Primer,Stream
Inheritance path: Primer,Streamable
Inheritance path: Primer,Streamable,WinPrimer
Inheritance path: Primer,Streamable,WinPrimer,Dialog
Inheritance path: Primer,Streamable,WinPrimer,Dialog,DialogModal
Inheritance path: Primer,Streamable,WinPrimer,Dialog,DialogModal,DialogAbout
Inheritance path: Primer,Streamable,WinPrimer,Window
Inheritance path: Primer,Streamable,WinPrimer,Window,Splitter
Inheritance path: Primer,Streamable,WinPrimer,WinApp
Inheritance path: Primer,Streamable,WinPrimer,WinApp,SdiApp
Inheritance path: Primer,Streamable,Array
Inheritance path: Primer,Streamable,WinPrimer,Button
Inheritance path: Primer,LinkedList
Inheritance path: Primer,Streamable,WinPrimer,WinControl
Inheritance path: Primer,Streamable,WinPrimer,WinControl,ComboBox
Inheritance path: Primer,Streamable,WinPrimer,WinControl,STATIC
Inheritance path: Primer,Streamable,WinPrimer,WinControl,BUTTONW
Inheritance path: Primer,Puntito
Inheritance path: Primer,ObjetoD
Inheritance path: Primer,Streamable,WinPrimer,Window,Bag01
Inheritance path: Primer,MUESTRASIM
Inheritance path: Primer,ItemLayout
Inheritance path: Primer,Layout
Inheritance path: Primer,Layout,GridLayout
Inheritance path: Primer,Streamable,WinPrimer,Window,GridW
Inheritance path: Primer,ACUo
Inheritance path: Primer,AnimalSim
Inheritance path: Primer,AnimalSim,AnimalModelo2
Inheritance path: Primer,Streamable,WinPrimer,Window,Resul02
Inheritance path: Primer,GDMRK
Inheritance path: Primer,GDMRK,GDMSIM
Inheritance path: Primer,Streamable,WinPrimer,WinApp,SdiApp,DemoApp02
\masm32\Projects\odm01\DemoMuestra.inc(338) : Error A2100: Nesting level too deep
MacroLoop(1): iteration 1: Macro called from
MacroLoop(5): iteration 1: Macro called from
lst_create(10)[misc.inc]: Macro called from
ll_MathTokenize(15)[math_tokenizer.inc]: Macro called from
fSlv8(51)[SmplMath.inc]: Macro called from
\masm32\Projects\odm01\DemoMuestra.inc(338): Included by
\masm32\Projects\odm01\Demo02_Main.inc(436): Included by
\masm32\Projects\odm01\engine.inc(17): Included by
IncludeObjectSrc(4)[Objects.inc]: Macro called from
MakeObjects(1)[Objects.inc]: Macro called from
Demo02.asm(76): Main line code
\masm32\Projects\odm01\DemoMuestra.inc(338) : Error A2100: Nesting level too deep
ll_move(8)[linked_list.inc]: Macro called from
tmt_on_oprt(65)[math_tokenizer.inc]: Macro called from
MacroLoop(6): iteration 2: Macro called from
ll_MathTokenize(111)[math_tokenizer.inc]: Macro called from
fSlv8(51)[SmplMath.inc]: Macro called from
\masm32\Projects\odm01\DemoMuestra.inc(338): Included by
\masm32\Projects\odm01\Demo02_Main.inc(436): Included by
\masm32\Projects\odm01\engine.inc(17): Included by
IncludeObjectSrc(4)[Objects.inc]: Macro called from
MakeObjects(1)[Objects.inc]: Macro called from
Demo02.asm(76): Main line code
\masm32\Projects\odm01\DemoMuestra.inc(338) : Error A2100: Nesting level too deep
ll_move(10)[linked_list.inc]: Macro called from
tmt_on_oprt(65)[math_tokenizer.inc]: Macro called from
MacroLoop(6): iteration 2: Macro called from
ll_MathTokenize(111)[math_tokenizer.inc]: Macro called from
fSlv8(51)[SmplMath.inc]: Macro called from
\masm32\Projects\odm01\DemoMuestra.inc(338): Included by
\masm32\Projects\odm01\Demo02_Main.inc(436): Included by
\masm32\Projects\odm01\engine.inc(17): Included by
IncludeObjectSrc(4)[Objects.inc]: Macro called from
MakeObjects(1)[Objects.inc]: Macro called from
Demo02.asm(76): Main line code
\masm32\Projects\odm01\DemoMuestra.inc(338) : Error A2100: Nesting level too deep
ll_move(36)[linked_list.inc]: Macro called from
tmt_on_oprt(65)[math_tokenizer.inc]: Macro called from
MacroLoop(6): iteration 2: Macro called from
ll_MathTokenize(111)[math_tokenizer.inc]: Macro called from
fSlv8(51)[SmplMath.inc]: Macro called from
\masm32\Projects\odm01\DemoMuestra.inc(338): Included by
\masm32\Projects\odm01\Demo02_Main.inc(436): Included by
\masm32\Projects\odm01\engine.inc(17): Included by
IncludeObjectSrc(4)[Objects.inc]: Macro called from
MakeObjects(1)[Objects.inc]: Macro called from
Demo02.asm(76): Main line code
\masm32\Projects\odm01\DemoMuestra.inc(338) : Error A2100: Nesting level too deep
ll_move(37)[linked_list.inc]: Macro called from
tmt_on_oprt(65)[math_tokenizer.inc]: Macro called from
MacroLoop(6): iteration 2: Macro called from
ll_MathTokenize(111)[math_tokenizer.inc]: Macro called from
fSlv8(51)[SmplMath.inc]: Macro called from
\masm32\Projects\odm01\DemoMuestra.inc(338): Included by
\masm32\Projects\odm01\Demo02_Main.inc(436): Included by
\masm32\Projects\odm01\engine.inc(17): Included by
IncludeObjectSrc(4)[Objects.inc]: Macro called from
MakeObjects(1)[Objects.inc]: Macro called from
Demo02.asm(76): Main line code
\masm32\Projects\odm01\DemoMuestra.inc(338) : Error A2100: Nesting level too deep
ll_move(38)[linked_list.inc]: Macro called from
tmt_on_oprt(65)[math_tokenizer.inc]: Macro called from
MacroLoop(6): iteration 2: Macro called from
ll_MathTokenize(111)[math_tokenizer.inc]: Macro called from
fSlv8(51)[SmplMath.inc]: Macro called from
\masm32\Projects\odm01\DemoMuestra.inc(338): Included by
\masm32\Projects\odm01\Demo02_Main.inc(436): Included by
\masm32\Projects\odm01\engine.inc(17): Included by
IncludeObjectSrc(4)[Objects.inc]: Macro called from
MakeObjects(1)[Objects.inc]: Macro called from
Demo02.asm(76): Main line code
\masm32\Projects\odm01\DemoMuestra.inc(338) : Error A2100: Nesting level too deep
ll_move(39)[linked_list.inc]: Macro called from
tmt_on_oprt(65)[math_tokenizer.inc]: Macro called from
MacroLoop(6): iteration 2: Macro called from
ll_MathTokenize(111)[math_tokenizer.inc]: Macro called from
fSlv8(51)[SmplMath.inc]: Macro called from
\masm32\Projects\odm01\DemoMuestra.inc(338): Included by
\masm32\Projects\odm01\Demo02_Main.inc(436): Included by
\masm32\Projects\odm01\engine.inc(17): Included by
IncludeObjectSrc(4)[Objects.inc]: Macro called from
MakeObjects(1)[Objects.inc]: Macro called from
Demo02.asm(76): Main line code
\masm32\Projects\odm01\DemoMuestra.inc(338) : Error A2100: Nesting level too deep
ll_move(41)[linked_list.inc]: Macro called from
tmt_on_oprt(65)[math_tokenizer.inc]: Macro called from
MacroLoop(6): iteration 2: Macro called from
ll_MathTokenize(111)[math_tokenizer.inc]: Macro called from
fSlv8(51)[SmplMath.inc]: Macro called from
\masm32\Projects\odm01\DemoMuestra.inc(338): Included by
\masm32\Projects\odm01\Demo02_Main.inc(436): Included by
\masm32\Projects\odm01\engine.inc(17): Included by
IncludeObjectSrc(4)[Objects.inc]: Macro called from
MakeObjects(1)[Objects.inc]: Macro called from
Demo02.asm(76): Main line code
\masm32\Projects\odm01\DemoMuestra.inc(338) : Error A2100: Nesting level too deep
ll_insert(22)[linked_list.inc]: Macro called from
tmt_on_oprt(135)[math_tokenizer.inc]: Macro called from
MacroLoop(6): iteration 4: Macro called from
ll_MathTokenize(111)[math_tokenizer.inc]: Macro called from
fSlv8(51)[SmplMath.inc]: Macro called from
\masm32\Projects\odm01\DemoMuestra.inc(338): Included by
\masm32\Projects\odm01\Demo02_Main.inc(436): Included by
\masm32\Projects\odm01\engine.inc(17): Included by
IncludeObjectSrc(4)[Objects.inc]: Macro called from
MakeObjects(1)[Objects.inc]: Macro called from
Demo02.asm(76): Main line code
\masm32\Projects\odm01\DemoMuestra.inc(338) : Error A2100: Nesting level too deep
ll_insert(24)[linked_list.inc]: Macro called from
tmt_on_oprt(135)[math_tokenizer.inc]: Macro called from
MacroLoop(6): iteration 4: Macro called from
ll_MathTokenize(111)[math_tokenizer.inc]: Macro called from
fSlv8(51)[SmplMath.inc]: Macro called from
\masm32\Projects\odm01\DemoMuestra.inc(338): Included by
\masm32\Projects\odm01\Demo02_Main.inc(436): Included by
\masm32\Projects\odm01\engine.inc(17): Included by
IncludeObjectSrc(4)[Objects.inc]: Macro called from
MakeObjects(1)[Objects.inc]: Macro called from
Demo02.asm(76): Main line code
\masm32\Projects\odm01\DemoMuestra.inc(338) : Error A2100: Nesting level too deep
ll_insert(25)[linked_list.inc]: Macro called from
tmt_on_oprt(135)[math_tokenizer.inc]: Macro called from
MacroLoop(6): iteration 4: Macro called from
ll_MathTokenize(111)[math_tokenizer.inc]: Macro called from
fSlv8(51)[SmplMath.inc]: Macro called from
\masm32\Projects\odm01\DemoMuestra.inc(338): Included by
\masm32\Projects\odm01\Demo02_Main.inc(436): Included by
\masm32\Projects\odm01\engine.inc(17): Included by
IncludeObjectSrc(4)[Objects.inc]: Macro called from
MakeObjects(1)[Objects.inc]: Macro called from
Demo02.asm(76): Main line code
\masm32\Projects\odm01\DemoMuestra.inc(338) : Error A2100: Nesting level too deep
ll_insert(26)[linked_list.inc]: Macro called from
tmt_on_oprt(135)[math_tokenizer.inc]: Macro called from
MacroLoop(6): iteration 4: Macro called from
ll_MathTokenize(111)[math_tokenizer.inc]: Macro called from
fSlv8(51)[SmplMath.inc]: Macro called from
\masm32\Projects\odm01\DemoMuestra.inc(338): Included by
\masm32\Projects\odm01\Demo02_Main.inc(436): Included by
\masm32\Projects\odm01\engine.inc(17): Included by
IncludeObjectSrc(4)[Objects.inc]: Macro called from
MakeObjects(1)[Objects.inc]: Macro called from
Demo02.asm(76): Main line code
\masm32\Projects\odm01\DemoMuestra.inc(338) : Error A2100: Nesting level too deep
ll_insert(28)[linked_list.inc]: Macro called from
tmt_on_oprt(135)[math_tokenizer.inc]: Macro called from
MacroLoop(6): iteration 4: Macro called from
ll_MathTokenize(111)[math_tokenizer.inc]: Macro called from
fSlv8(51)[SmplMath.inc]: Macro called from
\masm32\Projects\odm01\DemoMuestra.inc(338): Included by
\masm32\Projects\odm01\Demo02_Main.inc(436): Included by
\masm32\Projects\odm01\engine.inc(17): Included by
IncludeObjectSrc(4)[Objects.inc]: Macro called from
MakeObjects(1)[Objects.inc]: Macro called from
Demo02.asm(76): Main line code
There is not response after the errors. The english expression have run from me, but in spanish we say "se cuelga".
later: HJWasm comebak:
\masm32\Projects\odm01\DemoMuestra.inc(338) : Fatal error A1105: Out of Memory
Perhaps in the logo you can show that it's de 32 version. HSE
Hi HSE,
I have built here special for you 32 bit version with 80 level macro nesting,
however, I don't take responsibility if something goes wrong
I have added in this version data definition directive 'DY' data for YMMWORD
you have to change in your sources and windows.inc line 12948 dy to _dy
MOUSEINPUT STRUCT
_dx DWORD ?
_dy DWORD ? ;windows.inc line 12948
mouseData DWORD ?
dwFlags DWORD ?
time DWORD ?
dwExtraInfo DWORD ?
MOUSEINPUT ENDS
Hey hutch,
Could it be possible to change _dx to dx_ and dy to dy_ in windows.inc
this is because of having data definition directive 'DY' data for YMMWORD
mov eax, [ecx].MOUSEINPUT.dx_
looks beter than
mov eax, [ecx].MOUSEINPUT._dx
for the reason
MOUSEINPUT STRUCT
dx_ DWORD ?
dy_ DWORD ? ;windows.inc line 12948
mouseData DWORD ?
dwFlags DWORD ?
time DWORD ?
dwExtraInfo DWORD ?
MOUSEINPUT ENDS
it is defined in winuser.inc
as well as in HELPWININFOA, HELPWININFOW, MDICREATESTRUCTA, MDICREATESTRUCTW, NMLVSCROLL
There is another in line 19071 of Windows.inc:
NMLVSCROLL STRUCT
hdr NMHDR <>
_dx DWORD ?
_dy DWORD ?
NMLVSCROLL ENDS
There is a .for macro in ObjAsm32
:t
Thanks habran for the experiment!
But nothing change. I have used the little test writed by rrr, and results are exactly the same: only 39 works.
Viewing in your code, the same error is emitted when MAX_MACRO_NESTING, MAX_SEG_NESTING, MAX_IF_NESTING or MAX_RSP_NESTING are exceded. Perhaps it's posible a different message for a different error.
I'll investigate if there is a good reason to limit it to 40 levels and report it here 8)
As it can be seen below other definitions are connected to the MAX_MACRO_NESTING
/* input buffers
* 1. src line stack ( default I86: 2*600 = 1200 )
* 2. tokenarray ( default I86: 150*12 = 1800 )
* 3. string buffer ( default I86: 2*600 = 1200 )
*/
#ifdef __I86__
#define SIZE_SRCLINES ( MAX_LINE_LEN * 2 )
#define SIZE_TOKENARRAY ( sizeof( struct asm_tok ) * MAX_TOKEN )
#define SIZE_STRINGBUFFER ( MAX_LINE_LEN * 2 )
#else
#define SIZE_SRCLINES ( MAX_LINE_LEN * ( MAX_MACRO_NESTING + 1 ) )
#define SIZE_TOKENARRAY ( sizeof( struct asm_tok ) * MAX_TOKEN * MAX_MACRO_NESTING )
#define SIZE_STRINGBUFFER ( MAX_LINE_LEN * MAX_MACRO_NESTING )
#endif
Don't forget the test I wrote might be limited by the IF / ENDIF not the macros, when I get around to it I can do one without IF / ENDIF
Thanks rrr314159 :t
To remove all doubts about nesting I made this program, CreateNestedMacros.asm which creates a new file "NestedMacros.asm" with the requested number (levels) of nested macros. Then you compile this created asm file to see if the levels go that deep. It's possible to skip the intermediate file creation, by using macros to create the nested macros, but then it's hard (impossible?) to be sure just how many levels there are.
With JWasm64 it goes only to 20, blows up at 21. I don't know why my previous tester, which uses an IF / ENDIF construction, apparently can go twice as deep. But this program seems more authoritative. I also don't know why it seems to disagree with the JWasm setting at 40. You can also use this technique with ML, ML64, and JWasm 32-bit, they all give the same answer. Just modify this version appropriately. (Of course you'll have to modify the paths in the Compile batch files anyway).
The whole procedure is complicated enough that I threw in this instructions.txt:
Quote from: instructions.txtPurpose is to test how many levels deep Macro calls can go.
This is more complicated than it should be: 3 steps:
1) At top of CreateNestedMacros.asm set numberNestedMacrostoTest
2) at Command line run CreateNestedMacros.bat
3) then run CompileNestedMacros.bat
... you will see message "Nested Levels: --". If it's 0 you'll also see the error message, Error A2101: Macro nesting level too deep. Else it will be the number you entered (numberNestedMacrostoTest).
Sample run: (with 20 levels requested)
C:\NestedMacros>CreateNestedMacros
C:\NestedMacros>CompileNestedMacros
Nested Levels: 20
NestedMacros.asm: 94 lines, 2 passes, 0 ms, 0 warnings, 0 errors
Here's created "NestedMacros.asm" for 20 levels:
;================
echonum MACRO thenum, thetext:=<>
LOCAL ts$
ts$ TEXTEQU %thenum
% echo thetext &ts$
ENDM
;================
SumMacro0 MACRO NN
EXITM<NN>
ENDM
;================
SumMacro1 MACRO NN
EXITM <SumMacro0 (1 + NN)>
ENDM
;================
SumMacro2 MACRO NN
EXITM <SumMacro1 (1 + NN)>
ENDM
;================
SumMacro3 MACRO NN
EXITM <SumMacro2 (1 + NN)>
ENDM
;================
SumMacro4 MACRO NN
EXITM <SumMacro3 (1 + NN)>
ENDM
;================
SumMacro5 MACRO NN
EXITM <SumMacro4 (1 + NN)>
ENDM
;================
SumMacro6 MACRO NN
EXITM <SumMacro5 (1 + NN)>
ENDM
;================
SumMacro7 MACRO NN
EXITM <SumMacro6 (1 + NN)>
ENDM
;================
SumMacro8 MACRO NN
EXITM <SumMacro7 (1 + NN)>
ENDM
;================
SumMacro9 MACRO NN
EXITM <SumMacro8 (1 + NN)>
ENDM
;================
SumMacro10 MACRO NN
EXITM <SumMacro9 (1 + NN)>
ENDM
;================
SumMacro11 MACRO NN
EXITM <SumMacro10 (1 + NN)>
ENDM
;================
SumMacro12 MACRO NN
EXITM <SumMacro11 (1 + NN)>
ENDM
;================
SumMacro13 MACRO NN
EXITM <SumMacro12 (1 + NN)>
ENDM
;================
SumMacro14 MACRO NN
EXITM <SumMacro13 (1 + NN)>
ENDM
;================
SumMacro15 MACRO NN
EXITM <SumMacro14 (1 + NN)>
ENDM
;================
SumMacro16 MACRO NN
EXITM <SumMacro15 (1 + NN)>
ENDM
;================
SumMacro17 MACRO NN
EXITM <SumMacro16 (1 + NN)>
ENDM
;================
SumMacro18 MACRO NN
EXITM <SumMacro17 (1 + NN)>
ENDM
;================
%echonum SumMacro18 (2), Nested Levels:
.code
;================
start PROC
ret
start endp
;================
end
CreateNestedMacros.asm: 66 lines, 2 passes, 0 ms, 0 warnings, 0 errorsThe zip contains:
CreateNestedMacros.asm: creates NestedMacros.asm
NestedMacros.asm: a sample with 20 levels
CreateNestedMacros.bat: does what it says
CompileNestedMacros.bat: ditto (modify JWasm path here and next batch file)
CompileCreateNestedMacros.bat: this is run by CreateNestedMacros.bat. Seems clumsy but appears to be the simplest way to accomplish the objective
instructions.txt: as above
hope it's useful
[edit] of course if you just want to test 20 and 21 levels it's no trouble. Just compile the above NestedMacros.asm - see that it works - then it's very simple to add one more level (SumMacro19) and see that it doesn't.
It turns out that the "EXITM" counts as one macro, that's why the above only goes to 20 levels. Here's a new version which goes to 40 levels, and blows up at 41, like it should.
;================
echonum MACRO thenum, thetext:=<>
LOCAL ts$
ts$ TEXTEQU %thenum
% echo thetext &ts$
ENDM
;================
SumMacro0 MACRO NN
%echonum NN + 2, Nested Levels:
ENDM
;================
SumMacro1 MACRO NN
SumMacro0 NN
ENDM
;================
SumMacro2 MACRO NN
SumMacro1 NN
ENDM
;================
SumMacro3 MACRO NN
SumMacro2 NN
ENDM
;================
SumMacro4 MACRO NN
SumMacro3 NN
ENDM
;================
SumMacro5 MACRO NN
SumMacro4 NN
ENDM
;================
SumMacro6 MACRO NN
SumMacro5 NN
ENDM
;================
SumMacro7 MACRO NN
SumMacro6 NN
ENDM
;================
SumMacro8 MACRO NN
SumMacro7 NN
ENDM
;================
SumMacro9 MACRO NN
SumMacro8 NN
ENDM
;================
SumMacro10 MACRO NN
SumMacro9 NN
ENDM
;================
SumMacro11 MACRO NN
SumMacro10 NN
ENDM
;================
SumMacro12 MACRO NN
SumMacro11 NN
ENDM
;================
SumMacro13 MACRO NN
SumMacro12 NN
ENDM
;================
SumMacro14 MACRO NN
SumMacro13 NN
ENDM
;================
SumMacro15 MACRO NN
SumMacro14 NN
ENDM
;================
SumMacro16 MACRO NN
SumMacro15 NN
ENDM
;================
SumMacro17 MACRO NN
SumMacro16 NN
ENDM
;================
SumMacro18 MACRO NN
SumMacro17 NN
ENDM
;================
SumMacro19 MACRO NN
SumMacro18 NN
ENDM
;================
SumMacro20 MACRO NN
SumMacro19 NN
ENDM
;================
SumMacro21 MACRO NN
SumMacro20 NN
ENDM
;================
SumMacro22 MACRO NN
SumMacro21 NN
ENDM
;================
SumMacro23 MACRO NN
SumMacro22 NN
ENDM
;================
SumMacro24 MACRO NN
SumMacro23 NN
ENDM
;================
SumMacro25 MACRO NN
SumMacro24 NN
ENDM
;================
SumMacro26 MACRO NN
SumMacro25 NN
ENDM
;================
SumMacro27 MACRO NN
SumMacro26 NN
ENDM
;================
SumMacro28 MACRO NN
SumMacro27 NN
ENDM
;================
SumMacro29 MACRO NN
SumMacro28 NN
ENDM
;================
SumMacro30 MACRO NN
SumMacro29 NN
ENDM
;================
SumMacro31 MACRO NN
SumMacro30 NN
ENDM
;================
SumMacro32 MACRO NN
SumMacro31 NN
ENDM
;================
SumMacro33 MACRO NN
SumMacro32 NN
ENDM
;================
SumMacro34 MACRO NN
SumMacro33 NN
ENDM
;================
SumMacro35 MACRO NN
SumMacro34 NN
ENDM
;================
SumMacro36 MACRO NN
SumMacro35 NN
ENDM
;================
SumMacro37 MACRO NN
SumMacro36 NN
ENDM
;================
SumMacro38 MACRO NN
SumMacro37 NN
ENDM
;================
;================
SumMacro39 MACRO NN
SumMacro38 NN
ENDM
;================
SumMacro38 38
.code
;================
start PROC
ret
start endp
;================
end
This does 40, to try 41 just change the line near the bottom "SumMacro38 38" to "SumMacro39 39".
Here's the prog used to create the above, in case you ever want to test 256! Use the same .bat files and the same instructions as in the previous prog using EXITM.
;; Set numberNestedMacrostoTest to desired level. 20 works, 21 gives error "Nesting too deep"
numberNestedMacrostoTest = 41
;; ------------------------------------------------------------------------------------------------
numberNestedMacros = numberNestedMacrostoTest - 2
nNM$ textequ %numberNestedMacros
commentline textequ <;================>
%echo &commentline ;================
echo echonum MACRO thenum, thetext:=<>
echo LOCAL ts$
echo ts$ TEXTEQU %thenum
echo % echo thetext &ts$
echo ENDM
echo
%echo &commentline ;================
echo SumMacro0 MACRO NN
%echo %echonum NN + 2, Nested Levels:
echo ENDM
%echo &commentline ;================
echo
;***********************
echonumname MACRO thenum
;***********************
LOCAL ts$, thenumminus1
thenumminus1 = thenum - 1
ts$ TEXTEQU %thenum
% echo SumMacro&&ts$ MACRO NN
ts$ TEXTEQU %thenumminus1
% echo SumMacro&&ts$ NN
%echo ENDM
%echo &commentline ;================
ENDM
;***********************
_loop = 0
REPEAT numberNestedMacros
_loop = _loop + 1
echonumname _loop
ENDM
echo
%echo SumMacro&nNM$ &nNM$
echo
echo .code
%echo &commentline ;================
echo start PROC
echo ret
echo start endp
%echo &commentline ;================
echo end
echo
.code
start PROC
ret
start endp
end
rrr314159 did you try to build it with HJWasm32 with the 80 levels?
Sorry Habran, the HJWasm.exe from HJWasm32.zip (a few posts ago, Reply #4), also gives error A2100 with 41 nesting levels
Nasm has got 40 levels as well, for now I will leave it like that, perhaps later when I have more time I will try to improve that
H/JWasm is equal to MASM in this regard, and better in at least one circumstance, the recursion test, where MASM only does 20 levels. But the original problem was that MASM handled (some number of) levels while JWasm didn't. So obviously there's more to the story, it's not just about the 40 levels of nesting.
Hi!
I download MinGW-Gcc and succesfully compile JWasm13.
Changing the messages found that was MacroLevel what throw the error. I don't have a clue of what it means but I change MAX_MACRO_NESTING to 80, and erase all the objects previously compiled. The new compilation work perfectly. The first rrr test support 79 levels now and the second test reach SumMacro77 :t.
(Of course that don't explain the differences between compilers, the question remains)
Thanks. HSE
Hi HSE
Glad it works for you :t
As I said before I'll look at it bit later when I get some more time
I have uploaded new version at the top of the trad with 4 new instructions:
VGATHERDPD, VGATHERQPD, VGATHERDPS, VGATHERQPS
now there are available 8 new instructions:
VGATHERDPD xmm1, [rdi+xmm7*2], xmm2
VGATHERDPD ymm1, [rdi+xmm7*2], ymm2
VGATHERQPD xmm1, [rdi+xmm7*2], xmm2
VGATHERQPD ymm1, [rdi+ymm7*2], ymm2
VGATHERDPS xmm1, [rdi+xmm7*2], xmm2
VGATHERDPS ymm1, [rdi+ymm7*2], ymm2
VGATHERQPS xmm1, [rdi+xmm7*2], xmm2
VGATHERQPS xmm1, [rdi+ymm7*2], xmm2
VPGATHERDD xmm1, [rdi+xmm7*2], xmm2
VPGATHERDD ymm1, [rdi+ymm7*2], ymm2
VPGATHERQD xmm1, [rdi+xmm7*2], xmm2
VPGATHERQD xmm1, [rdi+ymm7*2], xmm2
VPGATHERDQ xmm1, [rdi+xmm7*2], xmm2
VPGATHERDQ ymm1, [rdi+xmm7*2], ymm2
VPGATHERQQ xmm1, [rdi+xmm7*2], xmm2
VPGATHERQQ ymm1, [rdi+ymm7*2], ymm2
HJWasm logo will now display 32bit or 64bit on HSE riquest
Here is fixed version for rip instruction somedata[rip+reg*8]
EDIT:
Sorry, it was buggy, I had to remove it till I fix it
habran, yes it's buggy, didn't seem to recognize include files
Thanks rrr314159,
I'll Be Back 8)
Fixed :bgrin:
Because I have introduced 3 new data definition directive 'DO' data for XMMWORD, 'DY' data for YMMWORD and 'DZ' for ZMMWORD you have to fix headers where you have do, dy, dz by replacing them with do_, dy_, dz_
There is also in ocidl.inc:
line 2720 STDMETHOD Do, :ptr IOleUndoManager replace with STDMETHOD Do_, :ptr IOleUndoManager
line 2789 STDMETHOD Do, :ptr IOleUndoManager replace with STDMETHOD Do_, :ptr IOleUndoManager
The problem I have appears unrelated to do, dy, dz. 64-bit simply isn't recognizing include files. For instance first error I get is "Symbol not defined: INFINITE", which is used by thread routine from an include. If I define it in the .asm, get "Symbol not defined: TRUE", the next one in the include. etc.
OTOH 32-bit (without -win64 option) found two dy's in windows.inc to fix, then ran, but the prog didn't work right. I could track down what went wrong if you want, but at least include files are recognized correctly.
Don't sweat it on my account, I'm fine using the older version
It is running flawlessly on my laptop
I am using windowsinc and I tested it on my other project
Do you use VS13 and if yes, did you install HJWasm targets?
I am curios if Johnsa has the same problem
Hi Johnsa,
thanks for finding the bug with REP MOVS
It was easy to fix ones when we know what is the bug and what is causing it
it was in codegen.c:
if( CodeInfo->prefix.ins != EMPTY && (CodeInfo->token < T_VPGATHERDD && CodeInfo->token > T_VGATHERQPS))
tmp = InstrTable[ IndexFromToken( CodeInfo->prefix.ins )].allowed_prefix;
and was supposed to be:
if( CodeInfo->prefix.ins != EMPTY && (CodeInfo->token < T_VPGATHERDD || CodeInfo->token > T_VGATHERQPS))
tmp = InstrTable[ IndexFromToken( CodeInfo->prefix.ins )].allowed_prefix;
here it is:
New problem now :( :(
918:
919: vmovaps xmm7,pt1
000000013F9D47C8 C5 FC 28 3D 50 5F 00 00 vmovaps ymm7,ymmword ptr [pt1 (013F9DA720h)]
920: vmovaps xmm8,pt2
000000013F9D47D0 C5 7C 28 05 58 5F 00 00 vmovaps ymm8,ymmword ptr [pt2 (013F9DA730h)]
921: vmovaps xmm9,pt3
000000013F9D47D8 C5 7C 28 0D 60 5F 00 00 vmovaps ymm9,ymmword ptr [pt3 (013F9DA740h)]
922: vmovaps xmm10,pt4
000000013F9D47E0 C5 7C 28 15 68 5F 00 00 vmovaps ymm10,ymmword ptr [pt4 (013F9DA750h)]
923:
xmm stuff seems to be assembling as ymm and i'm getting funny crash from it:
Unhandled exception at 0x000000013F5A47D0 in test.exe: 0xC0000005: Access violation reading location 0xFFFFFFFFFFFFFFFF.
I assume because the ymm's are only 16byte aligned and not 32 (so the ymm read would be unaligned).
Thanks Johnsa, :t
I'll check it :dazzled:
Hi Johnsa,
I have changed alignment to be able to align to 32 and it works, even though it complains:
warning A4130: Incompatible with segment alignment: 32
I tested it and it works properly on my laptop
please test this one
Hi,
Yeah I know about the warning with align 32, but that's not the problem. The problem is that it's (incorrectly) assembling SIMD(128bit) instructions to their AVX(256bit) equivalents.
So:
vmovaps xmm1,pt
is becoming
vmovaps ymm1,pt (once assembled).
Possibly related to the opcode-prefix emit again in codegen ?
Did you test this one, because it works as expected on my lap
CORRECT:
908: vmovaps xmm7,xmmword ptr pt1
000000013F5846D8 C5 F8 28 3D 40 60 00 00 vmovaps xmm7,xmmword ptr [pt1 (013F58A720h)]
WRONG:
909: vmovaps xmm8,pt2
000000013F5846E0 C5 7C 28 05 48 60 00 00 vmovaps ymm8,ymmword ptr [pt2 (013F58A730h)]
910: vmovaps xmm9,pt3
000000013F5846E8 C5 7C 28 0D 50 60 00 00 vmovaps ymm9,ymmword ptr [pt3 (013F58A740h)]
911: vmovaps xmm10,pt4
000000013F5846F0 C5 7C 28 15 58 60 00 00 vmovaps ymm10,ymmword ptr [pt4 (013F58A750h)]
It works IF and only IF you type out XMMWORD PTR.
If you leave that out, it get's it wrong, and it should know from the register what the size is (like it does in 2.13 and before).
How is it possible
Look this:
513: vmovaps ymm6,ymem
0000000000391508 C5 FC 28 74 24 30 vmovaps ymm6,ymmword ptr [ymem]
514: vmovaps xmm7,xmem
000000000039150E C5 F8 28 7C 24 50 vmovaps xmm7,xmmword ptr [xmem]
IF you declare the variable:
xmem XMMWORD 0,0,0,0
or
LOCAL xmem:XMMWORD
then it works too without the XMMWORD PTR on the instruction.
If the data is just in memory without the XMMWORD qualified type is when it doesn't work.
So in my case I use VirtualAlloc and point at that data, then it's wrong. I also use my own custom struct __mm128 which unions integer and float (like intrinsics).
If I point at that type it also doesn't work.
(This is working in 2.13 and before so it's some sort of regression in the latest version).
Try this:
909: vmovaps xmm7,[rsi] ;pt1
000000013FE046D8 C5 FC 28 3E vmovaps ymm7,ymmword ptr [rsi]
OK, now it doesn't compile properly
Thanks, I'll try to fix it ASAP
I have to go now, be back in 2 hours
in .data? section
Fixed :bgrin:
My 3 big test projects all work 100% now including some really hairy avx stuff and macro layers doing OOP! So far it looks good to go! :) :eusa_clap:
I'm still not able to link using the table+index style EA addressing.. and for some reason I cannot install VS2013 over my VS2012 Ultimate install I already have :( Although I don't see why VS2013 Link would behave any differently to 2012.
Good job!
I get plenty of errors, so I assume this is the 64-bit version 8)
JJ here is a 32 bit
test it please :biggrin:
Thanks Johnsa :t
AFAIK, if you want to link AVX2 you need VS13 linker
I am afraid that you will have to accept the reality
however VS15 Community will be soon availible
I have already installed VS15 Community RC and it works pretty good
Quote from: habran on July 19, 2015, 11:22:11 PM
JJ here is a 32 bit
test it please :biggrin:
Plenty of error messages for Windows.inc, line 12948:
MOUSEINPUT STRUCT
_dx DWORD ?
dy DWORD ?Same for line 19062:
NMLVSCROLL STRUCT
hdr NMHDR <>
_dx DWORD ?
dy DWORD ?
NMLVSCROLL ENDSUsing
_dy instead of dy makes MB assemble without errors, but that could break existing Masm32 code.
The pair _dx / dy is certainly inconsistent, but it's a bit late in the process to change Windows.inc; perhaps you can find the culprit in HJWasm which declares "dy" a reserved word...
Habran did mention earlier about making that change.
DO, DY and DZ are now reserverd data type defines (like DD,DW etc) for XMM,YMM and ZMM respectively.
I've changed the dy/dx in my windows.inc to _dy, _dx and so-far it has not caused any issue elsewhere.
Apart from that is it working ok?
Thanks Johnsa :biggrin:
JJ, I could build for you one version without DY, DO, DZ if you insist 8)
however, I suggest a compromise for you:
download WinInc and make those changes whenever you encounter error in includes and when you use HJWasm use
WinInc
Even if you cling to 32 bit, you will still be able to use AVX2 and AVX512 (first 8 registers) and for that reason you need
those data type defines
Uploaded new versions 32 and 64 bit at the top of this thread
Quote from: habran on July 20, 2015, 06:09:09 AM
JJ, I could build for you one version without DY, DO, DZ if you insist 8)
The problem is not me; it's everybody who ever used
dy in code (including, btw, the authors of Visual C).
Imagine you had a fat 50,000 lines source where one of your variables was called
dd. Then, some day, the authors of Masm say "from now on, we can use dd ? instead of DWORD ?" 8)
JJ here is one just for you without DO,DY,DZ ;)
Quote from: habran on July 20, 2015, 10:58:40 AM
JJ here is one just for you Masm32 users without DO,DY,DZ ;)
Works fine with MB and RichMasm sources :t
Has it become faster? RM with 16k lines assembles+links in 800ms on my i5, before it used to be 1000 with JWasm.
JJ thanks, I did not know that it is faster but I APOLOGIZE about it ;)
However, download it again because first one has some bugs
Try to assemble this one with the original Masm32 SDK:
include \masm32\include\masm32rt.inc
.code
start: MsgBox 0, "Hello World", "Hi", MB_OK
exit
end start
I did and it worked:
D:\masm32\bin>ml /c /coff /Cp /nologo /Fm /Zi /Zd hallo.asm
Assembling: hallo.asm
***********
ASCII build
***********
D:\masm32\bin>link hallo.obj /SUBSYSTEM:CONSOLE /RELEASE
Microsoft (R) Incremental Linker Version 5.12.8078
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
D:\masm32\bin>hallo.exe
D:\masm32\bin>
what was supposed to happen?
Good :t
Now try the same with D:\masm32\bin>HJWasm /c /coff /Cp /nologo /Fm /Zi /Zd hallo.asm
(with original \Masm32\include\windows.inc, 977412 bytes, 10 January 2012)
D:\>c:\jwasm\hjwasm /c /coff /Cp /nologo /Fm /Zi /Zd test.asm
Warning A4109: Invalid command-line option: /Fm
***********
ASCII build
***********
test.asm: 7 lines, 2 passes, 130 ms, 0 warnings, 0 errors
D:\>
Works for me. (CAVEAT: I have already updated all my include files to use _dx and _dy).
Quote from: johnsa on July 20, 2015, 09:56:10 PM(CAVEAT: I have already updated all my include files to use _dx and _dy).
And that's the problem - you have become incompatible with those people who use the original Masm32.
Such "minor" changes imply that two sorts of people are now in trouble:
1. noobs who are still fighting with the mysterious difference between "build all" and "console build all" now get the advice "when you plan to use ML, stick with the original SDK, otherwise edit Windows.inc bla bla"
2. very experienced members with large projects will see cryptic error messages, and are subsequently forced to devise a strategy how to make their projects compatible with two different assemblers, i.e. the ML+JWasm family on the one hand, and HJWasm on the other.
And all that to save a bit of typing, i.e. dy instead of ymmword...?
I suggest then as a compromise we add an new option directive:
OPTION DATATYPES:0
;ommission or default=0 which means DY,DO,DZ are not handled and types must be fully declared with YMMWORD, XMMWORD as per masm. 1 = implement DY/DO/DZ (for those who want it).
Perfect :t
Quote from: jj2007 on July 20, 2015, 11:01:05 PM
Perfect :t
It is easy to say but I have to sweat blood :dazzled:
Quote from: habran on July 20, 2015, 11:11:26 PMI have to sweat blood :dazzled:
Blood, Sweat and Tears! (https://www.youtube.com/watch?v=qi9sLkyhhlE) I know the feeling. JWasm often gave me a rough time when trying to remain compatible with all assembler versions >=6.15 :biggrin:
I am glad you are aware what are you doing to me, you and Johnsa, is that what your JJ mans Johan & John :P
Haha :) Have to keep you on your toes! And all these additions just help to make it awesome! ;)
I am just grumpy old f**t ;)
I have better idea about it :idea:
I will leave 32 bit compatible with masm32 without DO, DY, DZ
but 64 bit will have it built in
what do you reckon?
Quote from: habran on July 21, 2015, 06:54:15 AM
I have better idea about it :idea:
I will leave 32 bit compatible with masm32 without DO, DY, DZ
but 64 bit will have it built in
what do you reckon?
Sounds OK for me, but I can't speak for the 64 bit community :biggrin:
To me the most important is what you think ;)
Don't forget we can just use "option nokeyword:<dy>" if we don't want it, so it's not that big a deal. Conversely if you leave it out we can just use "dy equ YMMWORD", which I've already been doing when I find myself typing "ymmword" a lot. BTW have you fixed that bug where we have to put "xmmword ptr" even when the compiler should know the type? That's more important. Unfortunately I can't check it because your latest versions have problems with my weird code, as mentioned b4, and I haven't figured out why yet
QuoteDon't forget we can just use "option nokeyword:<dy>"
is the best thing :t
Quotehave you fixed that bug where we have to put "xmmword ptr" even when the compiler should know the type?
Yes sir 8)
Great, gives me incentive to figure out why my weird code (with many macros, does 32/64, SSE/AVX, real4/real8 all with same source) is having problems with latest versions.
BTW I've noticed another little bug which perhaps you could fix in your spare time :biggrin: . Often I intend to type, for example, "mov eax, ecx" but accidentally type, say, "mov ebx, ecx". Now, it's perfectly obvious from the flow of the code that I meant the first not the second: it's just a typo. And yet your HJWasm always uses ebx instead of what I obviously meant, eax (in this example). It's a small thing but very annoying, and if you could fix it I'd be grateful.
Thanks in advance ...
Hi TripleR,
HJwasm is still wearing nappies, when he grows a little bit I will send him to UNI to study telepathy ;)
hope you'll still be around :biggrin:
Quote from: rrr314159 on July 21, 2015, 09:45:26 AMNow, it's perfectly obvious from the flow of the code
3r,
You should at least give a few examples to Habran, so that he can derive the logic for HJWasm 8)
Surely an assemblers job is to assemble what you tell it, not for it to attempt to guess at your intention.
I don't think there is anyway that it could know you meant mov eax,ecx instead of mov ebx,ecx regardless of the flow. Your could be copying the value for the later use for all it knows!
My suggestion is.. don't make typos :) :)
I think the 32/64 should remain as similar as possible, so whatever solution we use it should be common to both. Either:
OPTION DATATYPE:1 ; for both (32/64) alike
Or we leave it as is (with new datatype directives) and people should use the nokeyword solution?
Let's take a vote on this.
I've tested the requirement of the xmmword ptr and it appears to be resolved in all my tests. vmovaps xmm(n),[rsi] ; for example assembles correctly and uses xmm instead of ymm.
That said do you have any indication as to what potentially is failing in your code rrr? (Is it run-time or assemble time error?, code or macro related?) Perhaps we can help narrow it down if it's some sort of regression that's occurred in the new versions.
Quote from: johnsa on July 21, 2015, 06:35:22 PMOr we leave it as is (with new datatype directives) and people should use the nokeyword solution?
You volunteer to explain "nokeyword" to the noobs in the next 20 years? Otherwise,
Quote from: rrr314159 on July 21, 2015, 09:09:08 AMwe can just use "dy equ YMMWORD", which I've already been doing when I find myself typing "ymmword" a lot
Quote from: jj2007 on July 21, 2015, 06:58:41 PM
Quote from: johnsa on July 21, 2015, 06:35:22 PMOr we leave it as is (with new datatype directives) and people should use the nokeyword solution?
You volunteer to explain "nokeyword" to the noobs in the next 20 years? Otherwise, Quote from: rrr314159 on July 21, 2015, 09:09:08 AMwe can just use "dy equ YMMWORD", which I've already been doing when I find myself typing "ymmword" a lot
I said a vote :) My vote is still for the new OPTION, saves me having to declare the equates and stops noobs from getting confused and generally keeps everyone happy and 32/64 working in the same way.
Quote from: johnsa on July 21, 2015, 07:05:20 PMMy vote is still for the new OPTION, saves me having to declare the equates and stops noobs from getting confused and generally keeps everyone happy and 32/64 working in the same way.
include \masm32\include\masm32rt.inc
; OPTION DATATYPE:1 ; error A2008: syntax error : DATATYPE
dy equ ymmword ; works like a charm
.code
start: print "Hello World"
exit
end start
DATATYPE is not built in yet ( and I wish to skip it if possible)
I am waiting for the forum's decision 8)
Quote from: jj2007 on July 21, 2015, 06:00:16 PM
Quote from: rrr314159 on July 21, 2015, 09:45:26 AMNow, it's perfectly obvious from the flow of the code...
3r, You should at least give a few examples to Habran, so that he can derive the logic for HJWasm
- One example, suppose we're using edi for an address, like "mov eax, [edi]". And suppose edi was zeroed previously in the routine; that there's also a statement assigning an address to esi like "lea esi, SomeDataLabel"; and that esi is never used. Then obviously I meant to assign the address to edi instead of esi.
The alternative is, I meant to use esi in the mov statement: "mov eax, [esi]". So HJWasm should simply check if either variation works better than the other, and use that one. It should NOT use the option that screws up the program, instead it should use the one that performs correctly - that's pretty simple isn't it? And if they both work fine, it can flip a coin.
If neither works, it will have to analyze the overall flow more carefully - there may be a few more typos floating around. For instance, perhaps I meant "mov esi, SomeDataLabel" because SomeDataLabel is actually a pointer. Or, perhaps I meant to write "invoke CreateThread,0,0,addr ThreadProc,rbx,0,0" instead of "mov eax, [edi]" - hey anybody can make a couple typos. Just add a little module to HJWasm that corrects the typos, so that the program works right: NOT so that the program works wrong. That's pretty clear isn't it?
Quote from: johnsaSurely an assemblers job is to assemble what you tell it, not for it to attempt to guess at your intention. I don't think there is anyway that it could know you meant mov eax,ecx instead of mov ebx,ecx regardless of the flow.
- That's
exactly what they said to the Wright Brothers - and now look at commercial aviation! If that doesn't prove my point, nothing will. I'm afraid you lack vision.
Quote from: johnsaThat said do you have any indication as to what potentially is failing in your code rrr? (Is it run-time or assemble time error?, code or macro related?)
- well as i said b4, for 64-bit it's compile-time, for 32-bit it's run-time (after taking care of those two "_dy"'s); and, I'll bet it's macro related. I need to check it more, but won't get around to it for a while. Probably habran can figure it out with that much to go on, after he takes care of the typo issue. Never underestimate the GodFather, you might wind up a floater in the Hudson River, your face eaten away by the crabs ...
re. the vote: I'd go with jj2007's opinion, require the equ statement instead of nokeyword; but whatever habran wants is fine with me, after all he's doing the work
Folks, 3rP is just pulling my leg ;)
In his own sneaky way, he is trying to say that he is happy with the development of HJWasm
Ok,
So we have:
No datatypes, use EQU for ymmword,xmmword,zmmword (if required): - 2 votes
Option nokeyword: - 0 votes
Option datatype: - 1 vote
So I say, let's leave it alone.. do the EQUs if you want them? (Less for Habran to do, and he can focus on more interesting tasks). :)
rrr, I'm still not sure I buy into the idea, it's making assumptions rather than following any real logic:
xor edi,edi
.
.
.
mov eax,[edi]
could be completely valid.. (For example when reading the IVT in system code).
lea esi,SomeDataLabel
This one I can sort of buy into, and could produce something akin to a compiler warning: "ESI assigned to but not used." or something. However once again the test would have to be confined to some level of scope,
say within the current PROC. The expectation may be to load ESI and return from the PROC with ESI set but not used, so in that case you'd get a warning when you don't really need one. I often do that with PROCS that have multiple return values.. so EAX=status, ECX=return count, ESI=ptr to returned data / buffer (even if it's breaking with stdcall/fastcall ABI) I know if I'm the only one using it it's fine and it's not going into a library/hll linkage scenario.
Basically want you're after is a full static-analysis, even in a high level language where the ability to determine the correctness of logic is far easier given the reduced combination of possibilities or usages is still quite hit and miss even using formal logical methods.
I definitely don't think the assembler should ever modify the code, warnings I can live with.. corrupted code due to the assembler "trying" to be smart not so much.
I have an idea floating in my head about how we could address these sorts of issues in the future and it's something that solves some other pain points too:
It's a very simple idea really (however it would probably require a completely new assembler to a degree) or at least the addition of a new front-end pre-parser.
To start with, I would like to add more scoping constructs, one primarily being namespaces.
Then I was thinking instead of a high-level language with inline assembler , what about an assembler with inline high level language?
So imagine something like:
MyProc PROC FRAME uses rbx argument1:DWORD, argument2:REAL4, argument3:DWORD
LOCAL i:DWORD
mov rsi,argument1
xor rcx,rcx
.HLL(exclude rsi,rcx)
for(i=0;i<argument3;i++)
{
[rsi++] = (argument2*2.0f)+sin(argument2) + (float)rcx;
rcx++;
}
.ENDHLL
ret
MyProc ENDP
Now the HLL parts could be processed via a true compiler model with AST and the expressions, types and correctness could be verified in a way similar to what you are looking for.
The HLL directive would specify which registers to be excluded during register allocation / compilation of the hll code. the HLL code could use variables exactly like a normal HLL, but could also directly manipulate registers as if they were variables.
In addition it would be nice to add CLASS and METHOD keywords, which do something similar to our OOP macro layers, but built-in with implict THIS ptr if it's declared as a method and not a proc.
Also.. I see no reason why we need to use invoke anymore
we should be able to just call by name with type checking and support for literal strings , float constants etc.
Basically the idea in my head is not so much about a set of specific features but rather lets think about ways to make writing assembler code faster, smarter, better WITHOUT it becoming a new language or just another derivative of C.
1) easier calling syntax
2) support for literals
3) namespace+using
4) class/method support with psuedo-templates.. no inheritance, probably some sort of contractual or prototypal implementation.
5) inline HLL blocks
6) a new standard library with containers (built around class/method), string functions etc..
Quote from: johnsa on July 21, 2015, 09:57:43 PMBasically want you're after is a full static-analysis, even in a high level language where the ability to determine the correctness of logic is far easier given the reduced combination of possibilities or usages is still quite hit and miss even using formal logical methods.
I definitely don't think the assembler should ever modify the code, warnings I can live with.. corrupted code due to the assembler "trying" to be smart not so much.
I have an idea floating in my head about how we could address these sorts of issues in the future
R3 just made a joke, but I see you are turning the joke into a serious project :t
However, why not use a pre-processor, instead of burdening the assembler with this "external" task? See here (http://masm32.com/board/index.php?topic=1998.0) for an example.
I think the idea has merit. Either there is no point in us using asm anymore, or we should be dreaming up "the next big thing".
I often find myself wondering if I should use C/C++ for a project simply because there are some things in asm which are a complete pain.. usually some form of mathematical expression
(I know SmplMath can help with some of that stuff).
(I will ignore the main argument being code maintainability..;)
If we could just "pop up" into some hll lines for some annoying tasks and then carry on in asm, rather than the original paradigm of "drop down" into some inline asm for speed (which you can't do anymore in VC 64bit anyway.. and I don't like linking in separate modules that much).. I think it would be pretty neat.
Quote from: johnsa on July 21, 2015, 10:39:15 PMIf we could just "pop up" into some hll lines for some annoying tasks and then carry on in asm
Great idea :t
(royalties on my bank account please (http://www.webalice.it/jj2006/MasmBasicQuickReference.htm))
Keep the pace!! I wil be expecting the telepathy module :biggrin: (perhaps typing the same little program at that time).
Btw, because the "so many tokens" error I change the size of line from 600 to 1600, and compiler is not crashing... yet.
Telepathy module will be available in my estimation about second half of 2031 ;)
We should beware of changing the essence of source code
Johnsa, if I decide to use some Hll, it would be in the first place preprocessor for precompiled headers
So we have conclusion for HJWasm about data types: leave it as it is
Seems so, delete the new operators DY/DZ/DX and just use equates if you want them.
Quote from: habran on July 21, 2015, 07:50:19 PM
Folks, 3rP is just pulling my leg ;)
In his own sneaky way, he is trying to say that he is happy with the development of HJWasm
- True, the telepathy module is a joke, altho it's inspired an interesting discussion which I intend to comment on. But the fact is, neither 32-bit nor 64-bit was working for me - I wouldn't joke about that, because if taken seriously it would cause extra headaches and work chasing down a non-existent bug.
The good news is both are working now. Didn't bother to figure out the problem with 32-bit (which did compile but then ran incorrectly) because the latest version is good. It may pop up again, and turn out to be as simple as the following:
The problem is / was, __JWASM__ is no longer defined: it used to be 211. You changed that to __HJWASM__ (=212).
So I'm all set now but I guess you should leave __JWASM__ defined? Remember when Japheth made his new version constant __JWASM__ but left the old MASM version intact, so as not to break existing code. Doesn't matter to me anymore but it might "gotcha" someone else.
Thanks for your great contributions to the community ... !
Are you saying this because you are really satisfied or because you are afraid of the Hudson River :bgrin:
OK, I'll delete the new operators DY/DZ/DX
Quote from: rrr314159 on July 22, 2015, 02:36:19 AMthe telepathy module is a joke, altho it's inspired an interesting discussion
We had started "FindBugs for Assembler (http://masm32.com/board/index.php?topic=1998.0)" two years ago, but it was limited to fairly simple things, such as comparing the number of pushs and pops in a procedure. Problem is to test such stuff you need bad code - and here in this forum you'll find only excellent coders :bgrin:
The topic has come up "how to improve HJWasm". (Everyone thought the telepathy idea was impractical.)
First, I'm well aware that I need to learn the program (a few month's work) before making suggestions about improving it. Unfortunately I'm not going to do that in any big hurry.
This brings up the key point: lack of people who know, and can work on, HJWasm. It's a pretty big project for one part-timer (two or three full-timers would be better). For this situation, "job #1" (as Ford used to say) should NOT be "improvements" but maintenance, basic bug-free operation - the nitty-gritty stuff that coding is mainly about. You know, many improvements are easy enough to implement, but every change, even a simple one, requires regression testing which can be a low-level (or major) pain for weeks. Only one type of "improvement" is necessary: upgrades, like RIP, AVX2 or 512.
Seems to me this is quite enough work for one part-time transplanted Aussie; plus habran throws in a few of his favorite improvements now and then, like new flugs. Obviously he can do whatever he wants (as far as I'm concerned; the police might object) but I'm figuring "next big thing" (to quote johnsa) improvement projects would not be a good idea. So until someone else masters HJWasm code (which is certainly an option) we (= everyone but habran) need to give up on the idea of major "improvements" to it.
Fortunately this doesn't mean we can't help improve HJ's effectiveness. One way is to write MACROs - if you don't know already, you'll be amazed what can be done with them. The other way:
auxiliary progs that support and work with HJ. That way anyone can do it, in any language they want; habran (or anyone else) doesn't even have to know about it.
There are various types of supporting programs. For instance jj's bug catcher (a "lint" program) analyzes source code, independent of the assembler, in the hope of catching mistakes. But the type I'm most interested in is a
pre-processor aux prog, which first massages the ("improved") source code then passes it along to HJ as legal code. With a batch file to call the preprocessor, then HJ (you can even use DOS pipes), it's transparent to the user and takes no time at all.
Of course I didn't invent the idea of pre-processors, HJ and almost every other language has one built-in (some, of course, have separate pp's as I recommend here). The built-in aspect is the problem: to modify HJWasm's preprocessor (macros, etc) you have to modify HJ itself. I'd prefer that HJ had more-or-less none of that stuff, it was all separate, but that's not necessary. HJ can be left exactly as is, with its (primitive but effective) preprocessing capability, but new stuff can be separate.
There are two good reasons to do it this way. The key problem it solves is manpower allocation. What you want is part-time people around the world able to work together. Of course they could work together on HJWasm but that's extremely not easy to coordinate. Instead let them work on separate progs entirely. The usually-big problem of coordinating the interface spec just doesn't exist here. The input to HJWasm is perfectly well known, and anyone writing a pre-processor can try it out on HJ anytime. When they have something worthwhile just post it. I can imagine habran getting involved somewhat; people might request some mod to the interface; but essentially it's a non-problem.
What would one do in one's preprocessing program? Well, I think the best thing about the H/J/Wasm line of assemblers (ML too of course) is actually the macros. You can (with limitations) make it do any HLL function, from simple math to classes with inheritance etcetera. But there are limitations. First it's a very primitive language, with IF statements, loops, simple assignment, some arithmetic, that's all. It should be (a bit) more sophisticated, along the lines of C I would say (the HLL ".if" statements are good - I'd like to see more of that). So I can write a prog to take in a text file (source code with a few new keywords I've invented: CLASS, or SCOPE, curly brackets, MAX, COS, whatever); change the code appropriately; and output a text file with legal HJ code. It's not as easy as it sounds but it's entirely do-able.
Other ideas: it's annoying that a macro can't get certain characters such as a semicolon. I'd like to grab the
entire line for parsing and preprocessing - semicolons and all. It could be syntaxed like "comment": grab everything between "pre-comment #" and "#", process as desired, paste the processed code back into the file, ship the legal code to HJ. That would allow, for instance, statements like "myvariable + myothervariable" with the + sign under my control - like overloading an infix operator - very readable. One could include debugging capability for one's preprocessor; and/or gradually implement HJ's macro capability also (write your own "REPEAT" for instance, and stop emitting to HJ), for functional modularity. BTW that's another good point, such a prog can be implemented incrementally; just one well-chosen simple feature, to start, could be quite useful.
The possibilities are endless, but my time/energy/enthusiasm isn't, and I doubt very much I'll do any of this. The point is, someone else can, independently (supported, of course, by the community, who provide ideas, testing, and applause). Six months should be enough to get somewhere. It could possibly in future be integrated with HJ, who knows. Would make a more convenient build, speed it up 25 or 33%, and integration would make it possible to emit better error messages; but it's not necessary.
To quote some of our most eminent members,
Quote from: habranJohnsa, if I decide to use some Hll, it would be in the first place preprocessor for precompiled headers
Quote from: jj2007However, why not use a pre-processor, instead of burdening the assembler with this "external" task?
- I agree!
Quote from: johnsathe HLL code could use variables exactly like a normal HLL
- I like your idea of "inline HLL". MasmBasic is something along these lines, but different. Don't you agree it could be done with a separate program as outlined above? A fair amount of start-up is necessary, dealing with the basics like includes and who knows what else, but in a few months you could make a good start on MasmCPlusPlus.
Quote from: johnsaIn addition it would be nice to add CLASS and METHOD keywords, which do something similar to our OOP macro layers, but built-in with implicit THIS ptr if it's declared as a method and not a proc.
- You know this can be done pretty well by building on structs. The only real stumbling block, it's impossible to get nice clean OOP syntax ("pre-comment" could cure that). Methods are worthwhile: you just define a code-label pointer as a struct element and write some supporting macros, like "method MACRO myObject, myMethod" to invoke it. E.g, "method CustomerData, PRINT_VERBOSE" meaning CustomerData.PRINT_VERBOSE ("THIS" can be done also of course). The syntax is, necessarily and unfortunately,
very clumsy - but that's curable with your new pre-processor prog (JOHNSAWasm).
Quote from: johnsaEither there is no point in us using asm anymore, or we should be dreaming up "the next big thing".
- hmmmm... There was a time I felt there was no point in getting out of bed in the morning if I couldn't achieve something remarkable that day. Now I realize: getting out of bed in the morning is the day's remarkable achievement! Similarly asm is its own justification, doesn't need be next or big.
Quote from: jj2007We had started "FindBugs for Assembler" two years ago, but it was limited to fairly simple things, such as comparing the number of pushs and pops in a procedure.
- One can't go too far with this "telepathy" or "lint" approach. For instance (as discussed in that thread) unmatched pushes and pops are perfectly legal in asm. And, a variable declared as dword might be used as real4 or even char, or of course pointer - there's essentially no type-checking, which is good. You could police proc args via the proto, I suppose; but as u said in that thread, makes sense for a noob tool, that's all.
- But perhaps a concordance might be useful: show all uses of eax or whatever, with options: only assignments, only pushes and pops, include the lines above and below, etc. Also proc/subroutine list, (alpha order, frequency order, proto's, .inc file and lib, etc), etc. And, a flow chart (both for asm code and preprocessor). In general, a prog which shows various aspects of the code, just for info not correction. It should be
very aware of macros, equ's: for instance, show the actual term, or else the expanded term, or both side by side, etc. If it understood how &works it could be a real boon. Might as well throw in pretty-print while you're at it. When you're done take a break for lunch then get back to work on MasmBasic :)
Hi rrr,
Surprisingly enough I had enough patience to read all through what you wrote, well done :t
I like your way of thinking and I seriously suggest you to write some book soon 8)
I agree with most of things you said and especially with this:
QuoteNow I realize: getting out of bed in the morning is the day's remarkable achievement! Similarly asm is its own justification, doesn't need be next or big.
One has to grow up to understand the meaning of that :eusa_clap:
I am busy at the moment with my w**k, and the most of my little free time I spend on finishing AVX512
As you can Imagine, it is very complex job with all of these new instructions and registers,
However, I am looking forward to the power we will get with them
My idea is to use precompiled headers instead of WinInc, that way we don't have to spend time and effort to keep up with all those new stuff
So, someone of you EMINENT programmers should roll the sleeves and get dirty
The preprocessor should be able to precompile both, 32 and 64 bit
Hi,
I agree that HJWASM should simply continue to develop through small bug-fixes and enhancements like rip, avx2, avx512.
As a "pure assembler" (assuming you include the basic HLL support and macros) it's pretty close on perfect with all those features in.
There isn't much more I could ask of it or want it to do.
I definitely think that any of these larger projects/ideas we have floating around are far too big for any one person to take on even full-time. We need a community effort to create them. They should either be new products or auxiliary products to complement the assembler.
I started some time back on an idea for a compiler which i called "fusion". The idea was that it supports multiple compilers (extensible even) through plugins. Each compiler shared a common core interface to sections
symbol tables, emit data, global state and so on. The objective was to be able to in a single source file mix and match whichever languages you want even with different execution targets.
In the Amiga days we used to code up copper-lists and stick them in the chip_mem section, which is kind of what inspired the idea.
Xeon Phi and shader code is an example, we could directly compile these in as part of a single source.
I think in the future than even high level languages will land up going this way as we realize that no one language is ideally suited to all problem domains. C# is a classic example of how we're already trying to jam different language-styles into one compiler, however I'm not totally convinced about the approach, or at least if it should be taken much further than it is without seriously harming the core of the language.
So this multi-compiler idea would allow you to write classes in different languages, even different methods of the same class or even blocks of code within the same method or procedure.
HLL inlined in asm would be a good example of this too.
.asm
lea rdi,myArray
xor rax,rax
mov rcx,sizeof(myArray)
rep stosq
lea rdi,myArray
lea rsi,mySourceArray
.hll(-rdi,-rsi)
for(dword i=0;i<myArray.length;i++)
{
[rdi++] = (dword)(sin([rsi])*cos([rsi++])*sqrt(i)*1000.0f);
}
.shader(glsl, fragment) as MyShader
varying vec3 normal;
varying vec3 vertex_to_light_vector;
void main()
{
// Defining The Material Colors
const vec4 AmbientColor = vec4(0.1, 0.0, 0.0, 1.0);
const vec4 DiffuseColor = vec4(1.0, 0.0, 0.0, 1.0);
// Scaling The Input Vector To Length 1
vec3 normalized_normal = normalize(normal);
vec3 normalized_vertex_to_light_vector = normalize(vertex_to_light_vector);
// Calculating The Diffuse Term And Clamping It To [0;1]
float DiffuseTerm = clamp(dot(normal, vertex_to_light_vector), 0.0, 1.0);
// Calculating The Final Color
gl_FragColor = AmbientColor + DiffuseColor * DiffuseTerm;
}
.xeonphi As MyXeonPhiCode
....
.asm
LoadCodeToXeonPhi(ADDR MyXeonPhiCode)
invoke My3DEngine::SetGPUShader, ADDR MyShader
.cpp
#include <xeonphi.h>
void LoadCodeToXeonPhi()
{
xeonPhiDriver->LoadCode(&MyXeonPhiCode);
}
.js
var quickIdea = [];
for(var i=0;i<100;i++)
quickIdea.push( (Math.cos(myArray[i])*100)|0 );
Or something to that affect :) (asuming you had asm,cpp,phi,js,hll and glsl shader compiler plugins)
I'm not suggesting we go ahead and try to accomplish this (it's a monumental undertaking) but maybe it gets the creative juices flowing about potential new ideas or things we could look to build into a pre-processor.
Just being able to use the standard Windows SDK (and it's headers) in asm, as they constantly update would be a fantastic accomplishment.
I am really impressed with your way of thinking, Johnsa
I don't think that it would be very hard to create that preprocessor, but that would give great adwantage to the assembler
Hi marlon!
Fortunatly there is a new entertainment for you:
Error A2102: Symbol not defined : @CatStr
A surprise in JWasm13 was that 80 macro levels is not enough for Biterider projects like ObjectBrowser. But Ml have no problem (Is something in ObjAsm interpreted as macro level by Jwasm and not by Ml?). At the moment the changes in global.h are:
#define MAX_LINE_LEN 1600 /* no restriction for this number */
#define MAX_TOKEN MAX_LINE_LEN / 4 /* max tokens in one line */
#define MAX_STRING_LEN MAX_LINE_LEN - 32 /* must be < MAX_LINE_LEN */
#define MAX_ID_LEN 547 /* must be < MAX_LINE_LEN */
#define MAX_STRUCT_ALIGN 32
/* v2.06: obsolete */
//#define MAX_RESW_LEN 31 /* max length of a reserved word */
#define MAX_IF_NESTING 20 /* IFxx block nesting. Must be <=32, see condasm.c */
//#define MAX_TEXTMACRO_NESTING 20
#define MAX_SEG_NESTING 20 /* limit for segment nesting */
#ifdef __I86__
#define MAX_MACRO_NESTING 120
#else
#define MAX_MACRO_NESTING 120 /* macro call nesting */
There is no hurry because, I see, the project is going to take all that last of the century :biggrin:
Amazing ideas for improvement. :t I can add the need for a findBugs capable of locate errors inside the macros. At present compiler very often say main.asm(xx): Exxx: error bla bla with no location of the error (of course there is no error in main.asm).
Thanks HSE
I will look at that soon
Hi,
for the preprocessor could we use the developments of HLA assembly language developed by Randall Hyde?
Hi LiaoMi,
I doubt that HLA can deal with 64 bit
We have to look how VC does precompiled headers and get some idea
Hi Habran,
Quote from: habran on July 25, 2015, 08:37:27 PM
I doubt that HLA can deal with 64 bit
We have to look how VC does precompiled headers and get some idea
but on the other hand, is it real necessary? I think the main things are:
- The assembler is up to date.
- Assembles well all the new instructions (that's a big challenge).
- The assembler is available under different Operating Systems (that would be a huge advantage).
Gunther
It is not necessary but it would make great leap forward and solve incompatibility of include files and keep them up to date
I don't think it will be hard to do. I will do it with pleasure, ones when I finish this job
Quote from: habranMy idea is to use precompiled headers instead of WinInc
- that would be great but I hope u don't mean "instead of" literally; rather, "in addition to". I'd want to retain the option of using a custom header file also.
Quote from: GuntherI think the main things are:
•The assembler is up to date.
•Assembles well all the new instructions (that's a big challenge).
•The assembler is available under different Operating Systems (that would be a huge advantage).
- assembling the new instructions shouldn't be a separate bullet from "up to date", but that's nit-picking :) Other OS's would definitely be a huge advantage but also, undoubtedly, a huge job (how much work is involved to port it to just one other OS, for instance, your favorite flavor of linux?)
- Anyway - I hate to be a party pooper - but I must disagree, the "mainest" thing is bug-killing. There is no such thing as a (moderately complex) piece of software that's bug-free, HJWasm no exception. The only way it can be "bug-free" is, nobody uses it, so you never know about the bugs! I personally know of at least two in HJWasm that I'll post someday when I find the time to isolate them in a test prog, and I feel habran isn't working hard enough :)
Quote from: HSEFortunatly there is a new entertainment for you: Error A2102: Symbol not defined : @CatStr
...
A surprise in JWasm13 was that 80 macro levels is not enough for Biterider projects like ObjectBrowser. But Ml have no problem (Is something in ObjAsm interpreted as macro level by Jwasm and not by Ml?). ... There is no hurry because, I see, the project is going to take all that last of the century :biggrin:
- Thanks HSE ... I think right now this is actually the most important post for HJWasm. I imagine the @CatStr prob is not a bug, rather HSE is doing something wrong. "80 macro levels" is also no bug, but it
is something that the "competition" - ML - does better. Here is a
user (the lifeblood of a project like HJ) who instead must go to the competition. Keeping him happy is job #1, not so much for his sake, but to show that the HJ team (of one!) responds - something the ML team (MicroSoft) doesn't do. HSE is nice enough to say "no hurry", but ...
Quote from: LiaoMifor the preprocessor could we use the developments of HLA assembly language developed by Randall Hyde?
- HLA was implemented as a preprocessor, is that right? If Randall Hyde's source code is available then it's a good place to start. At least I'd look at it for ideas. If RH is still around no doubt he'd be happy to give some tips. Translating to 64-bits is no big deal. Having said that, it's easier to do it yourself than try to adapt someone else's code; but I always review anything similar to my project for ideas, and maybe even some snippets. In the same spirit if I were doing "MasmC++" I'd take a good look at ObjAsm (which I've never done, intend to someday) since it's a related idea; and pick Biterider's brain as appropriate.
Quote from: johnsaI definitely think that any of these larger projects/ideas we have floating around are far too big for any one person to take on even full-time.
- If they are they simply will never happen.
- The only reason for more than one person on such a job is schedule. If it
must be done in a timely fashion u need as many people as it takes. But one person is at least 33% more efficient than any team. In a loose situation like this - unpaid volunteers on the internet - one person is infinitely more efficient, because you'll never get two people to cooperate on anything. It's true, I hear success stories about GitHub etc, teams of people working together effectively; that's great; but I bet it's a rare miracle, and temporary. And every time it works, someone (emphasis on
one) has already created a basic prog to elaborate on. Most such attempted collaborations end in mutual contempt, with no product in sight.
- For "MasmC++" the first step (a.k.a. milestone) is: make a preprocessor that works seamlessly, and simply replaces all instances of the word "CLASS" with "STRUCT" (for instance). That's a 1-person job which will take anywhere from a few days to a few weeks. Then, take the next step ... and the next ... if it takes 5 or 10 years, so what? No competition is going to eat your lunch by beating you to market. And if they do, great: saves you the trouble of writing it.
- I might be accused of inconsistency, since I said HJWasm could use 2 or 3 people: but that's because it is time-constrained. If things go well there should be a bunch of users all complaining about bugs, or at least requiring a response to show them what they're doing wrong. If they're not dealt with quickly they're gone and your project is pointless. Of course habran could do it just for his own use; nothing wrong with that; but I don't think that's his object here.
- Most likely I have more experience than anyone here technical-directing software projects. I've scoped out 1 man-month projects, on up to 10,000 man-year projects (only assistant t.d. on those). Most commonly, projects of 10 man-years or so.
- Now, even when programmers are in the same building, and are paid to do what you tell them, it's tough: they always know better than you, and spend half their time telling the secretary all about it. on the internet - with unpaid volunteers, all of whom have much better ideas than me (that's a given) - it's impossible. Would you do a job I scoped for you? Of course not. Neither will anyone else. Would I take the assignment of telling a bunch of you people what to do? With no pay? Of course not. It would require a lot of my time to do it right; no one will listen to me anyway; and I'd make plenty of mistakes (I, and every other t.d., always do); you'd expect perfection and wouldn't get it, go away in disgust at my first idiot blunder. Herding cats would be heaven by comparison. There's just no such thing as a multi-person project in these circumstances.
- I still say "MasmC++" can get well underway in 6 months (part-time) and in 5 years, you could have a good product. Plus any work done on it won't be waste: you can post it, and some one else can either build on it, or learn from your mistakes. But (and this is
the great thing about amateur software): it's your call.
Hi rrr,
Quote from: rrr314159 on July 26, 2015, 04:10:33 AM
- assembling the new instructions shouldn't be a separate bullet from "up to date", but that's nit-picking :) Other OS's would definitely be a huge advantage but also, undoubtedly, a huge job (how much work is involved to port it to just one other OS, for instance, your favorite flavor of linux?)
The availability on other operating systems was one of the advantages of jWasm in the past. We had versions for Windows(32- and 64-bit), DOS, OS/2, BSD and Linux. That should be the case in the future, too.
Gunther
Quote- that would be great but I hope u don't mean "instead of" literally; rather, "in addition to". I'd want to retain the option of using a custom header file also.
I meant OPTIONALLY
Headers with extension
.h will be preprocessed and
.inc will be left as they are
Quote from: rrr314159 on July 26, 2015, 04:10:33 AM
I imagine the @CatStr prob is not a bug, rather HSE is doing something wrong.
I agree. Just to note that habran's HJWasm(32) find a problem where habran's JWasm13(32) work fine. Perhaps the observation is usefull for habran, perhaps not.
Some issues I see aren't true compiler problem. Using ObjAsm32 and SmplMath push some limits:
fSlv8 [esi].AaDegEIN = [esi].FAaAla * [esi].HcAla + [esi].FAaArg * [esi].HcArg + [esi].FAaAsp\
* [esi].HcAsp + [esi].FAaGlu * [esi].HcGlu + [esi].FAaGly\
* [esi].HcGly + [esi].FAaIle * [esi].HcIle + [esi].FAaLeu\
* [esi].HcLeu + [esi].FAaPro * [esi].HcPro + [esi].FAaSer\
* [esi].HcSer + [esi].FAaThr * [esi].HcThr + [esi].FAaVal\
* [esi].HcVal + [esi].FAaPhe * [esi].HcPhe + [esi].FAaTyr\
* [esi].HcTyr;Lines like this could trouble the compiler, but it's for easy coding, because it's nothing sofisticated and using FPU instruccions there is no problem, except that corrections became a nightmare.
Regards, HSE
Quote from: rrr314159 on July 26, 2015, 04:10:33 AM"80 macro levels" is also no bug, but it is something that the "competition" - ML - does better.
I doubt there is a legit need for 80 levels, and suspect that some macro erroneously goes recursive and, well, stops precisely at the maximum allowed level. It would be nice if somebody could isolate this "bug" (which I've never seen in MasmBasic, with 400+ macros).
Gunther I didn't know JWasm had been for many other OS's - actually I sort of knew but forgot - so perhaps it shouldn't be a big problem. Still it doesn't happen by itself. If the HJ version for (e.g.) OS/2 were already ready just testing it would be a job ...
jj2007 you're prob right ... but may depend on what counts as a "level", for instance "EXITM" constitutes another level all by itself in some cases at least. And I love that phrase "it would be nice if somebody ["else" is implied :)] could ...". That is precisely the problem, who wants to do the work? (Who will bell the cat, to use an ancient proverb some may remember). That's why whatever does get done, is a one-person job
Hi rrr,
Quote from: rrr314159 on July 26, 2015, 09:33:32 AM
Gunther I didn't know JWasm had been for many other OS's - actually I sort of knew but forgot - so perhaps it shouldn't be a big problem. Still it doesn't happen by itself. If the HJ version for (e.g.) OS/2 were already ready just testing it would be a job ...
but it is. You could check this link (http://web.archive.org/web/20141010153046/http://www.japheth.de/JWasm.html) to verify it.
Gunther
Quote from: rrr314159 on July 26, 2015, 09:33:32 AM
If the HJ version for (e.g.) OS/2 were already ready just testing it would be a job ...
Quote from: Guntherbut it is. You could check this link (http://web.archive.org/web/20141010153046/http://www.japheth.de/JWasm.html)
- no, "HJ" is abbreviation for "HJWasm" not "JWasm". HJ may well be ready for OS/2, FAIK, but hasn't been tested (AFAIK)
Hi rrr,
Quote from: rrr314159 on July 29, 2015, 01:10:24 AM
- no, "HJ" is abbreviation for "HJWasm" not "JWasm". HJ may well be ready for OS/2, FAIK, but hasn't been tested (AFAIK)
lets not practice such superior attitude. The basis of jWasm was Watcom's Wasm, while the basis of hjWasm is jWasm. You can see this by checking the sources. So here's my question: Could you test hjWasm under OS/2, please? That would be a great help. I've only an old AMD K5 box running with OS/2 Warp 4. I think that's not good enough.
In the mean time I'll try to compile hjWasm for Linux and BSD. That's not a big thing. The maintainer for the jWasm fork is Habran, without any doubts. I think, he has the last word.
Gunther
Could you test hjWasm under OS/2, please?
- no, I have no OS/2 system. My point, which seems possibly to have been missed, is merely that until software is tested u don't know whether it works; that testing is a necessary job. Ask any program manager: if testing isn't necessary why is he paying all these people to do it?
Hi rrr,
Quote from: rrr314159 on July 29, 2015, 08:07:07 AM
- no, I have no OS/2 system. My point, which seems possibly to have been missed, is merely that until software is tested u don't know whether it works; that testing is a necessary job. Ask any program manager: if testing isn't necessary why is he paying all these people to do it?
testing is undoubtedly a necessary task. But jWasm works without problems under OS/2 and I think that at least hjWasm version 2.13 will also work, because Habran did change only 3 source code files. The appropriate DOS version works fine and you can download it here (http://masm32.com/board/index.php?topic=4444.msg47488#msg47488). But that must be tested.
Gunther
Quote from: GunnerI think that at least hjWasm version 2.13 will also work [for OS/2]
- agree, and after all it's hardly "mission-critical". DOS seems much more important
Hi rrr,
Quote from: rrr314159 on July 30, 2015, 01:04:49 AM
- agree, and after all it's hardly "mission-critical". DOS seems much more important
the DOS version has mainly some nostalgic reasons. OS/2 (I think it's now called eStation, or so) is another point. I hope that FORTRANS can help a bit. The critical part is that: We must find a working gcc under OS/2. The old version (I think version 3.x) was maintained by Eberhard Mattes from the University Stuttgart. But I've seen him not for a long time in the net. I hope he's doing fine. We'll see.
Gunther
Hi Gunther,
Quote from: Gunther on July 30, 2015, 08:17:52 AM
The critical part is that: We must find a working gcc under OS/2.
Maybe this page will help?
OS/2 port of the GNU C Compiler (http://os2ports.smedley.id.au/index.php?page=gcc)
Hobbes (OS/2 repository) has some old versions. EMX was
a programming environment that used a variant of gcc, if I
read things correctly.
HTH,
Steve N.
Thank you Steve, that could help.
Quote from: FORTRANS on July 31, 2015, 04:53:06 AM
Hobbes (OS/2 repository) has some old versions. EMX was
a programming environment that used a variant of gcc, if I
read things correctly.
Yes, with EMX maintained by Eberhard Mattes one could write OS/2
or DOS programs. It was a bit crazy, but it did work. Furthermore, some EMX binaries were necessary for the EmTex package (LaTex for OS/2), also maintained by Eberhard Mattes.
Gunther