ObjAsm

[Biterider]

Hello
I am happy that I have made great progress in the project ObjAsm Fusion.
The main goals of the project were:

   
• Merging the project ObjAsm32 and ObjAsm64 in one
• Develop an assembler code that can be assembled as x86 and x64 regardless of the target bitness
• Integrate the latest translated C header files generated from the h2incX project
• Introduction of Namespaces
• Introduction of Annotations
• Revised and modernized tool chain
• Support library for 32 and 64 bit
• New documentation

The reason for merging both projects is maintainability. I'll freeze ObjAsm32 like it is today and ObjAsm64 will not pass the beta phase. Instead, ObjAsm will cover both projects with a common code platform. Much work has been done to support this idea from proof-of-concept up to the included project. The aim of the fusion project was to ensure the best compatibility with the previous projects.

The second pillar of the project is the translated C/C++ header files. They are far from finished, but after the translation tool has been developed, missing files or new versions can be translated ad-hoc. The benefit of having the latest files is clear, but there are some challenges that needed to be addressed. One of them was naming conflicts.
The best solution was the introduction of the namespace concept. At the implementation level, the names of objects and members are mangled. COM members are also mangled, but not interface names. Doing so we avoid naming conflicts with the declared API names or other symbols. Now you have full freedom to use the name you want and reuse the names even in different namespaces.

Another improvement is the use of annotations. They are intended primarily for code analysis tools that will be released on a later stage.
The previous assembly tool chain has been completely revised using .cmd files. Sharing information with the RC compiler is implemented by pre-processing some files and automatically generating a file that is passed on. This strategy avoids synchronization issues but requires the use of the provided tools.

What will come next? The presented code base is not as complete as ObjAsm32. The code analysis tools need to be completed. For the h2incX project, a GUID extraction tool should be coded to complete the sGUID.inc file.

Nevertheless, it is a good start point and for the moment, I uploaded a "teaser", where the functionality can be checked.

As always, constructive comments are welcome!  :t

Biterider

[HSE]

Hi Biterider!!

Instructions say install uasm in the "...\ObjAsm\bin\tools" folder, but is searched in "...build\tools".

ObjMem32:

ErrorMessageBoxA.asm(25) : Error A2137: Conflicting parameter definition: dLangID
ErrorMessageBoxA.asm : 0 warnings, 1 errors
ErrorMessageBoxW.asm(25) : Error A2137: Conflicting parameter definition: dLangID
ErrorMessageBoxW.asm : 0 warnings, 1 errors

sdword2decA.asm(31) : Error A2137: Conflicting parameter definition: sdValue
sdword2decA.asm : 0 warnings, 1 errors
sdword2decW.asm(31) : Error A2137: Conflicting parameter definition: sdValue
sdword2decW.asm : 0 warnings, 1 errors

There is no "...\ObjAsm\Code\Objects\MakeObjects.cmd"

[Biterider]

Hi HSE
You are right, it should say "ObjAsm\Build\Tools". I will ask if I'm permitted to distribute if the future UASM together with ObjAsm.

The 2 bugs in ObjMem32 are there. I have corrected them.

The path configuration is located here "ObjAsm\Code\OA_Setup32.inc" or here "ObjAsm\Code\OA_Setup64.inc"
If wanted, I can upload the lib files to facilitate the installation.

I intentionally removed "...\ObjAsm\Code\Objects\MakeObjects.cmd" and the .asm files in the objects folder. For the moment include your objects using "MakeObjects".

Thanks!  :t

Biterider

[HSE]

The path configuration is located here "ObjAsm\Code\OA_Setup32.inc" or here "ObjAsm\Code\OA_Setup64.inc"
If wanted, I can upload the lib files to facilitate the installation.

I found the location just a minute after posting. I just change LibPath to were are already installed: \masm32\lib and \masm32\lib64\ (this machine is w7-64)

I intentionally removed "...\ObjAsm\Code\Objects\MakeObjects.cmd" and the .asm files in the objects folder. For the moment include your objects using "MakeObjects".

Most of the time I use MakeObjects because objects are builded with option Unicode and I using ANSI  .
I left in that mode because DednDave say always we have to make Unicode applications  :icon14: but I only know how to parse ANSI strings  :icon13:

Thanks!

[HSE]

Now in w7-32!

Some conditionality is required in OA_SET.cmd, example:

Code Select Expand

if [!TARGET_BITNESS!] == [32] (
    set Assembler="%OBJASM_PATH%\Build\Tools\UASM32.EXE"
) else (
  set Assembler="%OBJASM_PATH%\Build\Tools\UASM64.EXE"
)


[Biterider]

Hello HSE
I'm glad that you are looking so deep.  :icon14:

TARGET_BITNESS refers to the code being assembled.
UASM32 or USAM64 are a 32 and 64 bit application which can run on appropriate CPUs. Both are capable of generating 32 or 64 bit code.

The ObjAsm toolchain uses OA_BUILD.cmd that parses the .asm file in the main folder to determine how to set the TARGET_BITNESS variable. This way, the other tools can be configured automatically. This is done using the files in the "ObjAsm\Build\Options" folder.

Biterider

[Biterider]

Hello HSE
After I re-read your post, I believe that you want to automatically use the right tool.
I found this here https://support.microsoft.com/en-ch/help/556009. With this help we could choose UASM32 or UASM64 accordingly.
I'll take a look at it.

Biterider

PS:
Maybe something like this

Code Select Expand


reg Query "HKLM\Hardware\Description\System\CentralProcessor\0" | find /i "x86" > NUL && set SYSTEM_BITNESS=32 || set SYSTEM_BITNESS=64


if %SYSTEM_BITNESS%==32 (
  set Assembler="%OBJASM_PATH%\Build\Tools\UASM32.EXE"
) else (
  set Assembler="%OBJASM_PATH%\Build\Tools\UASM64.EXE"
)

[TimoVJL]

Code Select Expand

IF %PROCESSOR_ARCHITECTURE% == AMD64 (
ECHO x64
) ELSE (
ECHO x86
)
PAUSE

[Biterider]

Hi
Cool  :t
According to this ms official documentation https://docs.microsoft.com/de-ch/windows/desktop/WinProg64/wow64-implementation-details, would it not be safer to check for PROCESSOR_ARCHITECTURE=x86?

Biterider

[HSE]

Sounds good to use SYSTEM_BITNESS for tool selection  :t

How you set SYSTEM_BITNESS is a diferent question. Could be register, environment or manually method, not very important because you know what system you have and you have to modify this only once time.

[HSE]

Hi Biterider!

There is some problem with SmplMath functions with 2 arguments:

Code Select Expand

fSlv8 = max(10.0,0.0)

Code Select Expand

Error A2209: Syntax error: (0.0)) ? (10.0) : (0.0))>

[Biterider]

Hi HSE
That's great! You are using the translated header files   :t
Looking at the macro extension of max, I quickly found the name collision. MS defines max and min as macros in minwindef.inc and stdlib.inc.

To solve it, rename simplemaths operator or undefine min and max before including Simplemath (only UASM).
Something like:

Code Select Expand


SysSetup OOP, NUI32, ANSI_STRING, DEBUG(WND)

undef max
undef min

include D:\MASM32\SmplMath\macros\SmplMath\math.inc
include D:\MASM32\SmplMath\macros\macros.inc

Biterider

[HSE]

You are using some header files by default 

By the way msvcrt.inc is missing in package.

You can redefine macros and SmplMath's max macro is last one, my mistake stdlib was last one. (Just in case, with option NOMINMAX there is no definition of min and max macros in minwindef.inc, and I maked same thing in your stdlib.inc) <- that solve the problem.

Now I have to make a new hjwasm with more macrolevels!!

Thanks!

[Biterider]

Hi

By the way msvcrt.inc is missing in package.

As far as I know, there is no such thing like msvcrt.h. There are a bunch of header files to support the C++ runtimes.
Check this link https://support.microsoft.com/en-us/help/154753/description-of-the-default-c-and-c-libraries-that-a-program-will-link

Maybe someone who knows more about C ++ can give a better answer.  ::)

Biterider

[HSE]

Maybe someone who knows more about C ++ can give a better answer.  ::)

No problem. There is solid msvcrt.inc for Masm32 and Masm64, but are not automatics, and nobody can guarantee compatibility.

Apparently I lost my hjwasm13 source, but I build an AsmC with more macro levels and nestings.

Little problems in 32bit system:

Code Select Expand

Destroy [esi].LINKED_NODE.pObject                 ;Save dispose of linked Object

LinkedList.inc(130) : error A2052: forced error : MethodInvoke - unknown method: OA_LinkedList._pObject


Code Select Expand

fldReg eax

RNG.inc(389) : error A2032: invalid use of register