Sol_Asm: A new Assembler emerging

[BogdanOntanu]

I have another confession to make ;)

Once upon time when I have started making Sol_Asm ...
Sol_Asm  was "dual" in parsing: that is it was able to parse Sol_Asm syntax and MASM syntax.

But then I have seen POASM rising into existence and thought at the complications that dual mode parsing brings and removed MASM parsing from Sol_Asm.

Now I am thinking that maybe I could re-insert it for syntax that is present in include files like the windows.inc that Hutch has kindly created for MASM32. I guess this would also include Japheth's includes. However this would be a lot of work and would complicate parsing and error reporting system.

Another solution is a conversion program that can parse limites include like syntax and convert MASM syntax to Sol_Asm syntax.
Today I favor this idea more since it could be extended as a tool to be useful for others and other assemblers.

Mark Jones's idea is also very interesting but I see a downfall to it:

As it is today Sol_Asm has some algorithmically optimized routines for seeking symbols in a symbol table (searching for an EQU or a LABEL  or an PROC or an STRUC for example).

I can optimize his because I know the exact context of the operation. A SQL database can be fast but it has to be generic because it can assume much less about the DATA and CONTEXT of use that I can assume internally in Sol_Asm.

Because of this I consider that algorithmically speaking assemblers in general and Sol_Asm in particular will outperform any kind of database in a symbol Search mode.

Add to this the fact that having a full SDK database will take out a lot of space and CPU power to manage and this database size will again slow down search.

Besides Sol_Asm will only search what you include... sometimes you will include only what you need and sometimes you will include all windows.inc and then some more but my guess is that the handcrafted data set included by each and every project will still be orders of magnitude smaller that the whole SDK itself.

That beeing said I might still include a plug-in system in Sol_Asm that would allow Mark Jones to test out his ideas while using Sol_Asm parser to his advantage. No promises though just an intention.

[Vortex]

Hi Bogdan,

All of us, we understand that maintaining an assembler is not an easy job, take your time. You are doing a very nice job.

I converted two small demos to Sol_Asm. The first one is a console application displaying a NULL terminated string using C io streams.
The second one displays a simple dialog box based on the binary resource handling system. It uses the INCBIN statement to embed the binary resource template. Bogdan, maybe you could extend the capabilities of INCBIN to :

Code Select Expand

INCBIN filename.inc , OFFSET, Number_Of_Bytes

OFFSET represents the number of bytes skipped from the beginning of the file.
Number_Of_Bytes is the quantity of bytes to be included.

Working on the GUI demo, I detected that Sol_Asm does not recognize the statement jne :

Code Select Expand

**Error** Dlgbox.asm(47) Unknown Instruction: jne

To build the application properly, I replaced jne with jnz

[attachment deleted by admin]

[BogdanOntanu]

Hi Vortex,

Very nice examples, thank you.

And I observed the problems:
1) with manual stack balance :D
2) jnz versus jne

I will be fixing them. (Jnz was too simple so it is already fixed )

I will also extend the INCBIN directive in order to do what you request.

[hutch--]

Bogdan,

I downloaded the current version and had a good look at the text file that you supply with it and I have a reasonable idea of what the code type looks like. I had one reservation about the notation, the TASM ideal mode square bracketing around named variables in much the same way as NASM/FASM do it at the moment, any chance of making that non-compulsory ?

I gather the prototyping capacity will come in the future but it would certainly be virtuous to have a type checking method built into the assembler. By reading one of the earlier topics, I would avoid loading the executable with large volumes of equates as this is best done from external files which can be maintained seperately from the assembler.

Having looked at assembler for a long time I would be inclined to keep the capacity for proper Intel notation available as it is a very useful aid to wrk in another assembler if it supports Intel notation and the basic keywords like OFFSET, BYTE/WORD/DWORD PTR etc .... The Intel notation capacity in GAS made it a lot more usable without having to use that dreadful AT&T notation.

Progress with sol_asm looks good and its shaping up into being a very professional tool.  :U

[BogdanOntanu]

Bogdan,

I downloaded the current version and had a good look at the text file that you supply with it and I have a reasonable idea of what the code type looks like.

Hi Hutch,
Thanks you for your time and  interest in Sol_Asm.

I had one reservation about the notation, the TASM ideal mode square bracketing around named variables in much the same way as NASM/FASM do it at the moment, any chance of making that non-compulsory ?

Unfortunately no. My decission is not based on how NASM or FASM do things.

My logic tells me that using brackets around variables is the correct thing to do.

While I do understand why MASM creators did choose the other way around and I do respect their decission... I do not agree with them.

I agree that offset can add to the readability of the sources so I might add it as an recognized but "do nothing" keyword.

I gather the prototyping capacity will come in the future but it would certainly be virtuous to have a type checking method built into the assembler.

Yes, prototypes are planned for the future releases. Type checking also.

Currently Sol_Asm does check the PROC definitions in source code in order to extract PROTO information from the definition itself. Hence the need for PROTO is greatly reduced.


For example if you use at start of code: "invoke my_func1, param1, param2" and later on in source you define my_func1 to have 5 parameters then Sol_Asm will know and will emit an error. Sol asm will also adjust the stack for a CDECL function.

However the need for PROTO  is still present in 2 occasions:
1) For APIs imported because the API PROC definition is not in the user defined source code
2) Whenever the programmer wants to hint Sol_Asm "in advance" for speed issues.

By reading one of the earlier topics, I would avoid loading the executable with large volumes of equates as this is best done from external files which can be maintained seperately from the assembler.

That was my opinion also...

Having looked at assembler for a long time I would be inclined to keep the capacity for proper Intel notation available as it is a very useful aid to wrk in another assembler if it supports Intel notation and the basic keywords like OFFSET, BYTE/WORD/DWORD PTR etc ....

Sol_Asm does use Intel syntax and it does support byte/word/dword ptr notation . "PTR" is dummy and not needed but it is there simply for support reasons, I will probably add offset for the same reasons.

The Intel notation capacity in GAS made it a lot more usable without having to use that dreadful AT&T notation.

I have never ever considered GAS AT&T syntax as an acceptable syntax. I see it as what it is: hints from the higher level compiler for a less evolved or more simpler asm parser... however for humans that notation is insane... or at least for me that is. Good for them to add a "normal" syntax...

And thanks for the tip ;)

Progress with sol_asm looks good and its shaping up into being a very professional tool.  :U

I sure hope it does ;)

[Vortex]

Hi Bogdan,

Thanks for extending the INCBIN directive :U

[BogdanOntanu]

And BTW Hutch,

I have been thinking about your request also and although I have rejected it on first thought...

Now I think I will make the effort and allow "some" MASM style syntax as a "thank you" for the help I have received in time from Iczelion tutorials and the MASM32 include files and library.

'Some syntax" includes:
- no need for [variable_name] and the use of "offset" required for address
- structures defined with <name> STRUC as opposed to STRUC <name> in Sol_Asm
- MACRO defined with <name> MACRO as opposed to MACRO <name> in Sol_Asm

This behavior will be switched on/off with and "OPTION MASM" statement
I hope this will help MASM users to translate their source code and includes more easily into Sol_Asm syntax or even continue to use them as they are now.

But do not hold you breath for it... just know that I do intend to implement it sometime in the future. It has been there in the first early versions of Sol_Asm so I kind of know how to do it. I will implement it later during Sol_Asm development cycle: probably during beta or release candidate 1 phase.

[hutch--]

Bogdan,

Thanks for this mod, the compatibility with historical Intel notation in the form that MASM preserves will make what is looking like a very good assembler in development a tool that will be much easier to use by that vast number of programmers who are already experienced writing MASM style code.