Long lines UASM32

[johnsa]

There are definitely a bunch of non-pure C things through out the source which would need cleaning up if we wanted it to compile with any true C/C99 compiler. I guess the important question is..
is it worth it ? Who doesn't have a C/C++ compiler ? I'm open to suggestions on this..

[TimoVJL]

UASM is written in C. The source is portable and has successfully been tested with Open Watcom, MS VC, GCC and more.

;)
Why limit the msvc version requirement to the minimum of 2013?

[johnsa]

Fair call ;)

I'm happy to look at making the necessary changes for 2.49 then. 2.48 is just about out the door anyway, it's been taking quite some time!

[TimoVJL]

Good to hear that.
In my tests in windows gcc and clang are quite weak in this kind of sources.
Clang don't have own crt, it use M$ crt?
If someone have an icc, please give us compiled exe to test.

BTW: msvc is a right choice for Windows version, as version doesn't matter ;)
A big thanks for Andrea, Branislav, John :icon_cool:

[KradMoonRa]

2.48b version compiled with large lines and extra macros lib, and some clang fixe's.

Folder structure compiler used.

v141 = Visual Studio 2017 c++ compiler v15
v141_ICC19 = Visual Studio 2017 Intel c++ Compiler 19
v141_LLVM = Visual Studio 2017 LLVM-Clang c++ Compiler 9.0

Code: [Select]

https://github.com/eXOAMP/UASM/releases/download/eX.v2.48b1/Uasm-v2.48b.7z
https://github.com/eXOAMP/UASM/archive/eX.v2.48b1.zip


[TimoVJL]

So the  increased line length and nesting slowed down the speed :(

Code: [Select]

9.438s        uasm64.exe
23.478s       x64\uasm64icc.exe
24.273s       x64\uasm64llvm.exe
24.788s       x64\uasm64v141.exe

[jj2007]

So the  increased line length and nesting slowed down the speed :(

That looks pretty significant - a factor 2.5! Since it's caused by two MAX values, it seems a problem of logic. Have you tested decreasing those values, with a source that doesn't require long lines and/or deep nesting?

Sometimes I feel tempted to test MasmBasic's fast string array engine on UAsm, but unfortunately I am not the right person to dig inside C/C++ code :(

[TimoVJL]

Only a one test: MAX_LINE_LEN

Code: [Select]

9.594s        uasm64poc.exe 1024
10.826s       uasm64poc4k.exe 4096
11.388s       uasm64poc25K.exe 25600
EDIT: patch files for version 2.48 in git.
Should help to compile uasm with older msvc too.

[KradMoonRa]

Uasm-v2.48b1nolinenox86lib.zip has no modifications for large lines lenght and x86macros addition.
Uasm-v2.48b1withlinex86lib.zip has both modifications described above.

Code: [Select]

https://github.com/eXOAMP/UASM/releases/download/eX_v2.48b1/Uasm-v2.48b1nolinenox86lib.zip
https://github.com/eXOAMP/UASM/releases/download/eX_v2.48b1/Uasm-v2.48b1withlinex86lib.zip
https://github.com/eXOAMP/UASM/archive/eX_v2.48b1.zip


[TimoVJL]

Using that KradMoonRa global.h settings the speed difference was only 5% slower.
I still wait a good icc version to test, but if it just use a msvc runtime, nothing changes and in Windows msvc is a best choice.

[johnsa]

Hey,

I've been going through some of the patches and fixes and pushed a bunch into 2.48 (updated today).

it's not complete, and given my limited time I'm finding it quite hard to keep track of various messages, emails and forum posts all simultaneously.

If you guys take 2.48 master branch as it is today and generate a fork, could I ask if we could do other changes via Pull Requests ? That way I can keep track of it, and we can ensure we're keeping all the right non-experimental changes in  ?

I'll start a 2.49 branch shortly which we can use to then pull in all the remaining C/C99 and long-line changes. I would definitely consider looking at optimising the tokenizer for 2.49 so that long-lines shouldn't make a difference unless the line IS actually long.

PS Today's update included a fix that Biterider pointed out which is long-standing allowing 64bit imm's to go to memory without error.

John