News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests
NB: Posting URL's See here: Posted URL Change

Main Menu

ObjAsm

Started by Biterider, January 27, 2019, 02:32:00 AM

Previous topic - Next topic

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:
QuoteErrorMessageBoxA.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"


Equations in Assembly: SmplMath

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

Quote from: Biterider on January 31, 2019, 04:15:52 AM
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)

Quote from: Biterider on January 31, 2019, 04:15:52 AM
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  :biggrin:.
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!
Equations in Assembly: SmplMath

HSE

Now in w7-32!

Some conditionality is required in OA_SET.cmd, example:if [!TARGET_BITNESS!] == [32] (
    set Assembler="%OBJASM_PATH%\Build\Tools\UASM32.EXE"
) else (
  set Assembler="%OBJASM_PATH%\Build\Tools\UASM64.EXE"
)
Equations in Assembly: SmplMath

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


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

IF %PROCESSOR_ARCHITECTURE% == AMD64 (
ECHO x64
) ELSE (
ECHO x86
)
PAUSE
May the source be with you

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.
Equations in Assembly: SmplMath

HSE

Hi Biterider!

There is some problem with SmplMath functions with 2 arguments:
fSlv8 = max(10.0,0.0)
Error A2209: Syntax error: (0.0)) ? (10.0) : (0.0))>
Equations in Assembly: SmplMath

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:


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  :biggrin:

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!
Equations in Assembly: SmplMath

Biterider

Hi
QuoteBy 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

Quote from: Biterider on February 03, 2019, 09:28:51 PM
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:
Destroy [esi].LINKED_NODE.pObject                 ;Save dispose of linked Object

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


fldReg eax

RNG.inc(389) : error A2032: invalid use of register
Equations in Assembly: SmplMath