Hi all,
Here it is a new Solar Assembler release.
http://www.oby.ro/sol_asm/files/sol_asm_2007_10_07_bin.zip
The package contains:
- the Solar Assembler binary: sol_asm2.exe
- a brief documentation in file: read_me.txt
- 2 simple win32 samples in .\samples folder
- license agreement in file: LICENSE.TXT
For your reference, you can also see the brief description on-line here:
http://www.oby.ro/sol_asm/files/read_me.txt
Solar Assembler has evolved a lot since I have restarted it's development 3 months ago.
I've waited with this release until I was able to compile Solar_OS with SOL_ASM. This is a huge step forward since Solar_Os is a huge application and exposed many bugs in SOL_ASM.
Besides this way we have obtained our precious Independence Day for SOLAR OS ;)
I am serious about this product and I intend to make it of industry standard strength.
So please feel free to:
- criticize, test, bug report
- suggest improvement ideas
- request features you consider useful in an professional assembler
Here are a few features of special interest for MASM users:
- Invoke without PROTO
- Invoke with variables and symbols defined after it
- Invoke does parameter checking for Procedures defined later on in file(s)
It will have INVOKE and PROC and all of the HLL goodies in 64bits encoding mode.
The same thing will be functional for Win32, Win64, Solar_OS and Unix OS.
There will be plug-ins for cross compiling other architectures and OSes and user added features.
The development is accelerated, you can expect multiple releases in the next months.
You have the opportunity to request, debate and influence Solar Assembler syntax and features because it is not yet fully established.
Do not forget that this release is still tagged as "Alpha" so there are many miss features and bugs.
From my point of view this is the first "alpha" of Solar Assembler.
But it is also the the very first version that is practically usable and has proven itself at least against 2 very big applications.
:U :U :U
congratulate the great step.
I can do "typecast" with tbyte but there is no "dt" keyword mentioned in the list, strange. Not sure about the meaning of 'section "code" class_code' is this invented just to give user ability to choose whatever goes after the dot: '.code' '.biglazycode' '.c' .etc ? Confused regarding 'my_ps PAINTSTRUCT 0,1' do this substitute 'dup' and how to refer to second structure, oh yeah I haven't also noticed 'sizeof' in the keyword list, is this how I do it: invoke BeginPaint,[wnd_handle], my_ps+64 ? And here the last question go: what about resource compiler? I see no resource section (beginning with class_ ... )
Quote from: ramguru on October 07, 2007, 08:45:48 AM
I can do "typecast" with tbyte but there is no "dt" keyword mentioned in the list, strange.
You are right, thanks for pointing this out. Adding "dt" and "rt" now... as we speak ;)
I had a need for "tbyte" casting on some FPU code in Solar_OS but forgot to add "dt" and "rt".
And since we are at it... What would be the preferred syntax for 128 bits data type: "dh" or "do" ?
Quote
Not sure about the meaning of 'section "code" class_code' is this invented just to give user ability to choose whatever goes after the dot: '.code' '.biglazycode' '.c' .etc ?
"class_code" is just an easy way to say: readable executable initialized
"class_data" is just another way to say: readable writeable initalized
Of course that the detailed section flags will be added but for a start I have considered some simple commonly used section types.
And yes the user has the ability to choose section name and automatically what comes after "dot operator" in .data .code section selection. Hence, if defined, '.biglazycode' or".c" are perfectly valid section names. BTW you can have multiple similar sections for code or data etc.
Quote
Confused regarding 'my_ps PAINTSTRUCT 0,1' do this substitute 'dup' and how to refer to second structure,
In practice this syntax is not yet fixed but as it is now in that example there should be 2 (two) PAINTSTRUCT structures defined. First structure should be filled with 0 and the seccond one with 1. You can address them in the same way you address multiple data items declared on the same line or label.
If you intend to reserve data for 1024 of structures or as a substitute for "dup" you should use the "rs" keyword (reserve structure).
Quote
oh yeah I haven't also noticed 'sizeof' in the keyword list,
It is there, forgot to mention it. It is named SIZE.
This is valid:
mov eax, SIZE PAINTSTRUCT
I will tell you a secret ;)
SIZE is defined but "pro forma" only.
In fact the name of a structure does represent it's size in certain operations.
Hence you can simply write:
mov eax, PAINTSTRUCT
or
add esi, PAINTSTRUCT
Quote
is this how I do it: invoke BeginPaint,[wnd_handle], my_ps+64 ?
You can write something like that...
You can also do:
mov esi,my_ps
add esi, SIZE PAINTSTRUCT
...
invoke BeginPaint,[wnd_handle],esi
...
or
invoke BeginPaint,[wnd_handle],my_ps+<size PAINTSTRUCT>,...
And I guess I could also add this:
invoke BeginPaint,[wnd_handle],my_ps[N],...
Quote
And here the last question go: what about resource compiler? I see no resource section (beginning with class_ ... )
I will add a resource type for sections and later on a resource compiler.
If you have a better name or syntax for "class_ ..." I am open to suggestions.
Thanks you for questions, tips, criticism and comments...
keep them comming no matter if positive or negative since they do nevertheless provide hints for improvements.
After all this is just an alpha release ;)
Congratulations Bogdan, very nice work :U
Thanks Vortex and six_L for your kind words...
I hope to finish 64 bits encoding and win64 output long before ML64 is completly disabled and we all avoid having to write hand macro's for INVOKE, .IF and stuff like that ;)
Thanks for thorough explanation.
Quote from: BogdanOntanu on October 07, 2007, 09:41:50 AM
And since we are at it... What would be the preferred syntax for 128 bits data type: "dh" or "do" ?
Let's see it's 128 bits, so it's 16 bytes, so it's 8 words, we may say it's Octuple Word I guess 'do' would be OK.
Quote from: BogdanOntanu on October 07, 2007, 09:41:50 AM
If you have a better name or syntax for "class_ ..." I am open to suggestions.
I don't know, for me class referes to OOP maybe sec_ would make more sense.
Quote from: BogdanOntanu on October 07, 2007, 09:41:50 AM
It is there, forgot to mention it. It is named SIZE.
Thanks for letting me know that.
Quote from: BogdanOntanu on October 07, 2007, 09:41:50 AM
invoke BeginPaint,[wnd_handle],my_ps[N],...
I'm sure this syntax would be appreciated by many people, I find it a little too high level though.
Quote from: BogdanOntanu on October 07, 2007, 09:41:50 AM
Thanks you for questions, tips, criticism and comments...
So far there were questions & comments, criticism coming soon after I try it in one of my project (sorry I'm kinda busy these days, learning vhdl, verilog, systemC all that stuff.. since I mentioned verilog, your number representation 888_99_00 seems to be borrowed from that language :)
Hi Bogdan,
Trying to add the equate MessageBox equ <MessageBoxA> to your example code, I received an error message :
;------------------------------------------------------
; Sol_Asm assembler core
; Copyright (c) 2004-2007, Bogdan Valentin Ontanu.
; All rights reserved.
;------------------------------------------------------
;------------------------------------------------------------------
; This file is used to test Sol_ASM
; win32_pe format generation
;------------------------------------------------------------------
import_dll kernel32.dll
import_func ExitProcess
import_func GetStdHandle
import_dll user32.dll
import_func MessageBoxA
MessageBox equ <MessageBoxA>
section "code" class_code
section "idata" class_imports
section "data" class_data
STD_INPUT_HANDLE EQU -10
STD_OUTPUT_HANDLE EQU -11
.data
sz_message db "First Win32 PE application",0
sz_title db "Sol_ASM",0
.code
;invoke GetStdHandle, STD_INPUT_HANDLE
invoke MessageBox, 0, sz_message, sz_title, 3
Call ExitProcess
ret
nop
nop
Assembling file: test_win32.asm
Assembler pass: 1
**Error** test_win32.asm(18) EQU, expresion not defined? MessageBoxA
I get the same message when I add the equate following the definition of STD_OUTPUT_HANDLE Is there something that I miss?
Hi Vortex,
Yes, I forgot to mention that currently EQU result value can only be a number NOT a literal string.
TXTEQU is planed for a future release.
But I see your point here: many times text equates are used to define API names that have ASCII and UNICODE versions. And later on in code you can use a single API name for both UNICODE or ASCII versions of your application.
Maybe I can find a way to improve the import_func syntax a little an this way we could avoid typing a lot of such TXTEQU's
One way I could see it done as it is now would be to used #ifdef like this:
UNICODE EQU 1
#ifdef UNICODE
import_func Function_nameW
#else
import_func Function_nameA
#endif
or
MACRO MessageBox
MARG hwnd, lptext, lpcaption, utype
invoke MessageBoxA,hwnd,lptext,lpcaption,utype
ENDM
But I do agree it would be kind of complicated. This issue was noted ... Thanks for pointing it out to me
Hi Bogdan,
Thanks for the message. I asked about the equates because I am intending to create include files ( defining API functions ) for SolAsm.
Quote from: Vortex on October 07, 2007, 08:16:57 PM
Hi Bogdan,
Thanks for the message. I asked about the equates because I am intending to create include files ( defining API functions ) for SolAsm.
Oh, That would be outstanding! having include files for a new assembler is always a problem. Thank you.
Besides that fact that TXTEQU or friends will be implemented I was thinking of a quick fix for this API name issue.
What if I redefine import_func syntax like this:
...
import_func MesageBoxA as MessageBox
...
Adding the "as" keyword to give an user name for an API name.
This way the parser could know both symbols at compile time or only the last "as" or "alias" one
Is that any better... ?
Oh dear,
One thought that crossed my mind when thinking about this API name issue was:
from user32.dll import MessageBoxA as MessageBox
I confess ...
Hi Bogdan,
import_func MesageBoxA as MessageBox
and
from user32.dll import MessageBoxA as MessageBox
are both nice ideas.
I can modify my dll2inc tool to create the include files for Sol_Asm. Using my tool def2lib, I can create all the necessary MS COFF import libraries with decorated and \ or non-decorated symbols. The big work is to create the master window.inc file containing all the structure definitions and equates.
Quote from: Vortex on October 08, 2007, 04:37:47 PM
...The big work is to create the master window.inc file containing all the structure definitions and equates.
I am working on something like this now, except using a database. However we must check the SDK license to verify this is allowable. I needed drive space so deleted my SDK for the moment, and don't have near enough free space for the latest version. It would be a great help if someone could look into that.
Hi Mark,
Japheth created a nice set of include files. It's Public Domain :
QuoteWin32Inc is a set of include files for MASM or POASM created by h2incx. It contains all includes required to build Win32 applications or dlls. If you also have got PellesC (see the links page where to get it), there's everything available to create Win32-PE binaries in Assembler. Be aware that Win32Inc is intended for people being familiar with the command line interface and experienced in programming (not necessarily Assembler, however). There is also no installer supplied, just a compressed package of directories and files together with a simple README.TXT trying to explain things.
http://www.japheth.de/win32inc.html
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.
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 :
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 :
**Error** Dlgbox.asm(47) Unknown Instruction: jne
To build the application properly, I replaced jne with jnz
[attachment deleted by admin]
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.
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
Quote from: hutch-- on October 09, 2007, 06:23:23 AM
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.
Quote
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.
Quote
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.
Quote
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...
Quote
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.
Quote
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 ;)
Quote
Progress with sol_asm looks good and its shaping up into being a very professional tool. :U
I sure hope it does ;)
Hi Bogdan,
Thanks for extending the INCBIN directive :U
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.
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.