News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests

Main Menu

Long lines UASM32

Started by HSE, February 08, 2019, 12:18:48 PM

Previous topic - Next topic

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

QuoteUASM 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?
May the source be with you

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:
May the source be with you

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


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

TimoVJL

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

9.438s        uasm64.exe
23.478s       x64\uasm64icc.exe
24.273s       x64\uasm64llvm.exe
24.788s       x64\uasm64v141.exe
May the source be with you

jj2007

Quote from: TimoVJL on February 17, 2019, 08:23:02 PM
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

#22
Only a one test: MAX_LINE_LEN9.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.
May the source be with you

KradMoonRa


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


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
The uasmlib

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.
May the source be with you

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