HJWasm Releases

[TouEnMasm]

I know all that and use the normal crt winmain in my other sources

The version of Jwasm64 who offer no problem for me is this one:
http://masm32.com/board/index.php?topic=4256.msg45376#msg45376
No problem of Frame.
Perhaps made you your compile in an another system than Windows 10 ?

[habran]

Thanks Johnsa :t

HJWasm will automatically allocate and utilise the stack space (following the abi).

1) so a minimum of 32 bytes are always reserved
2) if you have 4+ args and shadow space enabled, the args will be copied
3) if you don't have shadow space enabled (which you always should by virtue of win64:11).. then no home space are used
4) irrespective of 2 and 3.. if there are unused slots in the homespace these will be used for non-volatiles (preserved via USES) AND / OR locals..
5) each proc will automatically determine the maximum shadow space requirement of all invokes within itself and adjust accordingly at prologue

So.. it's basically exactly what a C++ compiler would do with optimisations on.. except perhaps for using RSP for all references instead of RBP.

So.. based on that
1) NEVER use push/pop at all ever for anything..
2) NEVER touch RSP..
3) 1+2 will make your life much happier and trouble-free :)

Hey people, keep these things on your mind when you try to do something EXTRAORDINARY ::)

[GoneFishing]

JOHNSA,
GCC 4.8.4  build SUCCESSFUL, log attached
CHAHGES: strcmpi -> strcasecmp in hll.c and invoke.c
Note, that resulting 64 bit executable still reports :

HJWasm v2.13.32bit

Maybe add #ifdef  __UNIX__ case to globals.h ?

Today I'll try to write OWLinux.mak for Linux .  Original OWLinux.mak is supposed to generate Linux binary from Windows
( cross-compilation) .

[GoneFishing]

...
Ok,

1) I've modified assemble.c (line 253) to declare int i; before the loop.. as this should be more compatible then with non C99 compilers.. github updated.. again.. :)

Open Watcom 1.9 doesn't like chages you have made :

assemble.c(253): Error! E1077: Missing '}'
assemble.c(253): Error! E1077: Missing '}'
assemble.c(254): Error! E1099: Statement must be inside function. Probable cause: missing {
assemble.c(260): Error! E1099: Statement must be inside function. Probable cause: missing {
make: *** [OWLinuxR/assemble.o] Error 4

Initial version ( post #101, before changes) was OK

[johnsa]

...
Ok,

1) I've modified assemble.c (line 253) to declare int i; before the loop.. as this should be more compatible then with non C99 compilers.. github updated.. again.. :)

Open Watcom 1.9 doesn't like chages you have made :

assemble.c(253): Error! E1077: Missing '}'
assemble.c(253): Error! E1077: Missing '}'
assemble.c(254): Error! E1099: Statement must be inside function. Probable cause: missing {
assemble.c(260): Error! E1099: Statement must be inside function. Probable cause: missing {
make: *** [OWLinuxR/assemble.o] Error 4

Initial version ( post #101, before changes) was OK

The only thing I can think is to replace it with:

Code Select Expand


int i;
for (i = 0; i < len; i++)
{
CurrSeg->e.seginfo->CodeBuffer[idx++] = *(pBytes++);
}


Perhaps the compiler doesn't understand single line for's without the { }'s.. this is done and committed to git.

[johnsa]

JOHNSA,
GCC 4.8.4  build SUCCESSFUL, log attached
CHAHGES: strcmpi -> strcasecmp in hll.c and invoke.c
Note, that resulting 64 bit executable still reports :

HJWasm v2.13.32bit

Maybe add #ifdef  __UNIX__ case to globals.h ?

Today I'll try to write OWLinux.mak for Linux .  Original OWLinux.mak is supposed to generate Linux binary from Windows
( cross-compilation) .

Excellent!
Once we have an x86/x64 build I'll put them up on the site too and add the mak file to the repository.
The problem with __UNIX__ is it still won't determine if the compilation target is 32bit or 64bit...

Habran, how do you feel about just removing that from the console output? :)

[GoneFishing]

...
The only thing I can think is to replace it with:

Code Select Expand


int i;
for (i = 0; i < len; i++)
{
CurrSeg->e.seginfo->CodeBuffer[idx++] = *(pBytes++);
}


Perhaps the compiler doesn't understand single line for's without the { }'s.. this is done and committed to git.

Nope , still shows errors:

Code Select Expand


assemble.c(253): Error! E1077: Missing '}'
assemble.c(253): Error! E1077: Missing '}'
assemble.c(254): Error! E1099: Statement must be inside function. Probable cause: missing {
assemble.c(261): Error! E1099: Statement must be inside function. Probable cause: missing {
Error(E42): Last command making (OWLinuxR/assemble.obj) returned a bad status
Error(E02): Make execution terminated


OW wants and likes this :

Code Select Expand


//int i;
  for (; len; len--)
CurrSeg->e.seginfo->CodeBuffer[idx++] = *(pBytes++);
Is it the same ? I noticed this notation in FillDataBytes routine

Now it stops here:

Code Select Expand


directiv.c(264): Error! E1077: Missing '}'
directiv.c(264): Error! E1077: Missing '}'
directiv.c(264): Warning! W107: Missing return value for function 'IncBinDirective'
directiv.c(264): Error! E1011: Symbol 'file' has not been declared
directiv.c(264): Warning! W102: Type mismatch (warning)
directiv.c(264): Note! I2003: source conversion type is 'int '
directiv.c(264): Note! I2004: target conversion type is 'struct __iobuf *'
directiv.c(264): Note! I2002: 'ftell' defined in: /home/snark/Projects/OW19/binl/lh/stdio.h(290)
directiv.c(264): Error! E1011: Symbol 'fileoffset' has not been declared
directiv.c(264): Error! E1054: Expression must be constant
directiv.c(265): Error! E1009: Expecting ')' but found '0L'
directiv.c(265): Error! E1026: Invalid declarator
directiv.c(265): Error! E1009: Expecting ',' but found '0L'
directiv.c(265): Error! E1026: Invalid declarator
directiv.c(265): Error! E1026: Invalid declarator
directiv.c(265): Error! E1009: Expecting ',' but found '0'
directiv.c(265): Error! E1026: Invalid declarator
directiv.c(265): Error! E1009: Expecting ',' but found ')'
directiv.c(265): Error! E1026: Invalid declarator
directiv.c(266): Error! E1024: Declared symbol 'pBinData' is not in parameter list
directiv.c(266): Error! E1009: Expecting ',' but found '='
directiv.c(266): Error! E1009: Expecting ')' but found 'unsigned'
directiv.c(266): Error! E1026: Invalid declarator
directiv.c(266): Error! E1009: Expecting ',' but found 'char'
directiv.c(266): Error! E1026: Invalid declarator
directiv.c(266): Error! E1147: Too many errors: compilation aborted
Error(E42): Last command making (OWLinuxR/directiv.obj) returned a bad status
Error(E02): Make execution terminated


[johnsa]

Wooo... nothing has been changed there at all so it's not something I've done :)

Sounds like there is something wrong with OW (or it's options),

Code Select Expand


//int i;
  for (; len; len--)
CurrSeg->e.seginfo->CodeBuffer[idx++] = *(pBytes++);


that really shouldn't be necessary even in older C syntax.. they're semantically totally different (one is modifying the passed in parameter, the other is using a newly declared loop variable)... and all C supports an "init condition" section of the for loop..?!?

[GoneFishing]

Well , so it's two different things
Files directive.c in your initial commit and as it is now differ . You may compare them . If it's not you who changed the code  - then who else?

Anyways, tell me which compilers do you want to keep satisfied on Linux 

P.S.: I use original Japheth's makefile with my paths and it works fine with your initial code + modified codegen.c

[qWord]

In ANSI C / C89 definitions must be done at begin of functions - mixing statements and definitions is not allowed.
For Open Watcom 1.9, you can activate C99 support due to cmd-line option -za99.

[GoneFishing]

QWORD, you're a magician  :t
I've added this option to original makefile and it worked fine !

[johnsa]

Ok,

Can we then agree for any compiler / build-target it should support C99 and that option should be used to build the solution.. I think that's reasonable?
Or does anyone feel we should stick to full ANSI C compliance?

[GoneFishing]

Ok.
Valuable post : http://masm32.com/board/index.php?topic=1977.msg21753#msg21753
I didn't have luck with TCC today  (errors at link stage), it turned out that it can't handle redefs

[johnsa]

Ok... I decided to stick to ANSI C for now, I've modified all those functions to be ANSI C compliant and made the same changes to invoke.c and hll.c
(strcasecmp).. using #defines in globals.h to make that Windows compatible.
All work from my side in Visual C++
Github updated, GoneFishing do you want to try grab the full source / latest commit and make sure that works with OW / GCC and your make files?

Cheers

[GoneFishing]

Sure  :t
already going to GitHub