The MASM Forum Archive 2004 to 2012

Hi all,

Here is a new release of Sol_ASM, version 0.8.2 build on 2007_12_25
http://www.oby.ro/sol_asm/files/sol_asm_2007_12_25_bin.zip

And the on-line help text file:
http://www.oby.ro/sol_asm/files/read_me.txt

New things include among others:
- added some 16 bits encodings
- OBJ output OMF32, COFF (work in progress)
- listing output
- alias for API names
- improved "incfrom" binary include
- real4, real8, real10 floating point data defines
- added AND, NOT, OR, XOR to expressions
- many bugs fixed
- some instructions added

As always, comments, tests, bugs reports, requirements and suggestions are welcomed.

Hi Bogdan,

Very nice work, many thanks :U

Attached is the dialog box example using the new alias feature for external functions.

Bogdan, checking the MS COFF object files created with SolAsm, I noticed that the relocation type indicators are different for API functions.

SolAsm generated object files :

Constant   : IMAGE_REL_I386_DIR32
Value        : 0x0006
Description :The target's 32-bit VA.

Masm generated object files :

Constant   : IMAGE_REL_I386_REL32
Value        :  0x0014
Description :The 32-bit relative displacement to the target. This supports the x86 relative branch and call instructions.

Not sure but this could be a problem if you try to link SolAsm MS COFF object files with MS Link or Polink. Also, all the symbol table indexes in the relocation section are pointing the symbol named data. Polink links the object file but the executable is crashing because of this symbol table index issue.



[attachment deleted by admin]

Hi Vortex,

Thank you for checking Sol_Asm output.

MS COFF output is work in progress / not finished yet.
I have noted your observations about COFF output and I will fix them.

Hi, Bogdan
win32_gui example doesn't want to compile:

Assembling file: test_win32_01.asm
Assembler  pass: 1
**Error** test_win32_01.asm(61) STRUC, unknown initialization mode: 0
**Error** test_win32_01.asm(63) STRUC, unknown initialization mode: 0
**Error** test_win32_01.asm(65) STRUC, unknown initialization mode: 0
**Error** test_win32_01.asm(65) Unknown Instruction: 1


You have to edit test_win32_01.asm:
my_class WNDCLASS { 0 }

my_msg MSG  { 0 }

my_ps PAINTSTRUCT { 0 1 }

Note that spaces (or tabs) are required before and after { }. So that
my_class WNDCLASS {0}

would produce an error.

This is what readme file say about this:

QuoteStructure data definitions
-----------------------------

Structure definitions are automatically promoted as data types and
you can define a structure like this

   <structure_name>   <data_item>

For example:
   my_class   WNDCLASS   ?   
   my_ps      PAINTSTRUCT   ?

Defines one WNDCLASS structure at label "my_class" with initial value unknown,
and one PAINTSTRUCT structures at label "my_ps".

Structure member initializations:
-----------------------------------

Considering the structure:

STRUC Stru4
   x   db   ?
   y   dw   ?
   z   dd   ?
ENDS


You can initialize structure members like this:

   init2   Stru4      { 1 2 3 }            

   init2   Stru4      {  y = 2  z = 7  x = 1 }

The first version initializes members in sequence of their definition while
the seccond vesion initializes structure members by name.

You are, as you see, not required to use a "," between members. But, as test showed, there will be no error if you use  it.

Nick

Hi ramguru,

Thanks for testing.
And yes, that was my error because I have not checked and updated that sample's syntax.

You can fix it as TNick shows above or like this:

my_class WNDCLASS ?
my_msg MSG ?
my_ps PAINTSTRUCT ?


This form will leave the structures not initialized at compile time but is shorter to type ;)

I will update the samples.

Thank you both for clarifying (examples weren't up-to-date, I wasn't sure help file was, also it could be a little bit more user-friendly not a plain-text, hope this feature is coming soon  :wink ). Well, I'm also not a fan of such strict syntax as this assembler is starting to adapt:

Quote from: TNick on December 26, 2007, 11:15:26 AM
Note that spaces (or tabs) are required before and after { }. So that...

Everything else looks great, keep up the good work

Hi all,

Here is a new release of Sol_ASM, version 0.8.4 build on 2007_12_31.  Probably the last one this year :P

http://www.oby.ro/sol_asm/files/sol_asm_2007_12_31_bin.zip

And the on-line help text file:
http://www.oby.ro/sol_asm/files/read_me.txt

New things :
- DLL output
- emit raw documentation (procs, structs, equs) for your projects
- CDECL for import_func and cinvoke variation
- fixed some bugs

Hi Bogdan,

Thanks for this new release, I will try it :U

New version 0.8.6 silent update (ie same zip file and links as above).

Fixed some bugs:
===============
1) There was a critical bug in CDECL statement when used in connection with IMPORT_FUNC statement.
2) Also fixed the ".if eax == " bug. (unfinished .if did not generate an error in some situations)
3) Fixed the line numbers with "\" bug
4) Fixed an expression parser bug: ".if eax == 7xxh" was accepted without error

Hi Bogdan,

The win32_obj_coff example's MS COFF object file has the symbol table index problem. I can link it with Alink but executable is crashing when I run it.

Quote from: Vortex on January 01, 2008, 10:03:22 AM
The win32_obj_coff example's MS COFF object file has the symbol table index problem. I can link it with Alink but executable is crashing when I run it.

Hi Vortex,

Yes, you are right.
No changes have been done to the COFF output module yet..., but it is next on my list ;)

Hi Vortex,

Here is a new release of Sol_ASM, version 0.8.7 build on 2008_01_02

http://www.oby.ro/sol_asm/files/sol_asm_2008_01_02_bin.zip

Now COFF output works.

Small samples for building COFF executables with ALINK, MASM / MS LINK and POLINK are included.

Hi Bogdan,

Thanks, now the MS COFF output works :U

I found a trick to use a static library with SolAsm generated MS COFF object file. SolAsm generates jump tables to call external functions. To get working the final executable, I redirected the enrty point of the external module by inserting a DD instruction. My quick test is based on a simple Masm static library :

StdOut proc lpszText:DWORD

    LOCAL hOutPut  :DWORD
    LOCAL bWritten :DWORD
    LOCAL sl       :DWORD

    dd StdOut+4 ; Redirect the entry point of the function to skip the first 4 bytes

    invoke GetStdHandle,STD_OUTPUT_HANDLE
    mov hOutPut, eax
    .
    .
    .


[attachment deleted by admin]

The Digital Mars linker can link SolAsm OMF object modules. I tested the OMF Alink demo to build the executable.

Bogdan, the assembler sets the entry point as _main not _App_Init :

PUBDEF - Public Names Definition = 1A0
Base Group = FLAT
Base Segment = code
#1 = _main OFFSET = 2

The free DM tools are available from :

http://www.digitalmars.com/download/freecompiler.html

[attachment deleted by admin]

Hi Vortex,

Thank you for the samples, tests and suggestions ...  ;)

Quote
Bogdan, the assembler sets the entry point as _main not _App_Init :

Yes that is true.

I guess it is a left over from some of my tests... one of the linkers i have testes apparently wanted that symbol name to be defined  along with FLAT. I will check again if that hardcoded symbol name is in fact needed.

What you did there with StdOut is quite "a hack"; patching SOl_ASM's jump table to get imports from a static lib working :)
I guess it can only work for the first function imported from a LIB and for the last entry in the jump table.

But I see your point ;)
I will add static imports (extern) and static exports (export/public/global) to Sol_Asm.

Maybe I should rename the current "export" keyword to "export_func" to make it clear that it is an DLL kind of export an use the "export" keyword for the OBJ static kind of export.

Hi Bogdan,

Many thanks for your decision to support static libraries.

Bogdan, yes my method is a kind of trick but it's not limited with the first and last items. I added other functions to the test library and this didn't break anything.

A question, will it be possible to remove the import_dll statement targetting object file output? This statement has no any effect in object modules in my opinion.

[attachment deleted by admin]

Quote from: Vortex on January 03, 2008, 06:29:53 PM
Bogdan, yes my method is a kind of trick but it's not limited with the first and last items. I added other functions to the test library and this didn't break anything.

Yes I see that now, your method is general. "Mea culpa" ... please excuse my error.

Quote
A question, will it be possible to remove the import_dll statement targetting object file output? This statement has no any effect in object modules in my opinion.

Yes, that would be a possibility. Now I am thinking to a few options for static libs and OBJ output:

1) IMPORT_LIB


import_dll kernel32.dll
import_func ExitProcess alias __imp__ExitProcess@4

import_lib test.lib
import_func StdOut alias _StdOut@4


This will mark ExitProcess as an function imported from an DLL and StdOut as an function imported from an static LIB.
Additionally it could also paly the role of MASM includelib keyword.

2) EXTERN

extern StdOut alias _StdOut@4
extern ExitProcess alias _ExitProcess@4


This way you will not need a import_lib statement and will mark StdOut and ExitProcess as external symbols that are to be resolved by the linker in whatever way is possible (DLL or static lib).

I will probably implement both :D