I have released the first version of Sol_ASM.

It's primary target is to replace TASM in Solar_OS development. The secondary target is to provide a 16/32/64bits replacement/clone for MASM/TASM.

It is like a toy now but hopefully it will become a more proffesional gun. Enjoy it while it is still very simple and easy to understand.

Any comments / questions are welcome ...

Download sites are:
www.hostileencounter.com/sol_asm/sol_asm_2005_03_30.zip
www.oby.ro/sol_asm/sol_asm_2005_03_30.zip

There is a debug version that generates the ods.txt file where you can see details about its internal modus operandus.

What it does for now:
===============
-Output: bin only
-assembles some 32bit instructions (not all yet)
-labels
-PROCS, ARGS, LOCAL, USES
-structures
-include files

Kind of limited but it is very fast and nicely structured and easy to understand ;)

License is FASM / BSD style.

Windows console version for now. The final roadmap contains Solar OS, Linux and FreeBSD versions also.
Posted on 2005-03-30 11:18:05 by BogdanOntanu
Look nice, also yes, I recommend take a look, at less I have understood a little ;).


Hey bogdan, in your structs file you have defined a stru_stru structure, but for what you use those last members?? offset and segment, like I see a structure is only a model for access the memory and by this will not have to know where is it declared?


I dont know, but what you think of put the "links" in the first member instead of the third??



Dont know how fun this will be ;) and if will help in some..., but for the labels, why not create two list of hashes (in the first and more easy case ;)), one, containing all the labels declared in data section and one for the labels at code section ;) in that way, for each structure that you have of a label, you have repetition of such members in the structure ;). but if you have more than one hash be each segment, then you will delete some members of the struct, the how you search for them???

1 mov eax, labelX1
2 mov ecx,
3 cmp eax, labelX3
4 jxx labelX4
5 jxx


Like I see the majority of things related to movement and access of a memory are first related to data section ;), then 1,2,3 and 5 should be first searched in the labels of data and then in code and for things like 4 should be first searched in code.


Also if you take that in acount for some you will need also look forward in how to handle more sections, perhaps 4 hashes?? code, data, ?data all the others new sections?? (but the members of this last will have also the segment and offset that for delete this members was selected have more than one hash for the labels...  ;) :P)
Posted on 2005-03-31 09:26:47 by rea

Look nice, also yes, I recommend take a look, at less I have understood a little ;).


Sol_Asm as well as SolarOS are designed to be easy to understand as much as possible under the circumstances ;)
I promote a new kind of style in software/assembly : a style that is first easy to understand and only then optimized.


Hey bogdan, in your structs file you have defined a stru_stru structure, but for what you use those last members?? offset and segment, like I see a structure is only a model for access the memory and by this will not have to know where is it declared?


I do not remember why now :P it must have been some tests...
But I think they are added for the 16bits part of the code generation; like when you have USE16 and you need to know the segment:offset of any symbol.



I dont know, but what you think of put the "links" in the first member instead of the third??


Well maybe I should put the size_of_name the first member. Anyway does it matter?
Probably only for optimizations and there is much grunt work to be done before "optimizations".


Dont know how fun this will be ;) and if will help in some..., but for the labels, why not create two list of hashes (in the first and more easy case ;)), one, containing all the labels declared in data section and one for the labels at code section ;) in that way, for each structure that you have of a label, you have repetition of such members in the structure ;). but if you have more than one hash be each segment, then you will delete some members of the struct, the how you search for them???


So this is again a kind of optimization is it not?
It would complicate things a little but it might speed up the search a little?


1 mov eax, labelX1
2 mov ecx,
3 cmp eax, labelX3
4 jxx labelX4
5 jxx


Like I see the majority of things related to movement and access of a memory are first related to data section ;), then 1,2,3 and 5 should be first searched in the labels of data and then in code and for things like 4 should be first searched in code.


yeah somehow ...


Also if you take that in acount for some you will need also look forward in how to handle more sections, perhaps 4 hashes?? code, data, ?data all the others new sections?? (but the members of this last will have also the segment and offset that for delete this members was selected have more than one hash for the labels...  ;) :P)


Well sections are more related to OBJ output for now (in my mind)
But yeah if each "section" has it own symbol table than it makes sense.

I guess for SEGMENTS this might be TRUE and then yeah then the SEGMENT / OFFSET pair might have been designed for this also :D  .data . data? .code are only simplyfied versions of SEGMENT directives

Time will tell...



Posted on 2005-04-02 12:42:46 by BogdanOntanu
I support you to do the asm compiler work in the back. If you can do some explanations about the internels or the structure of the compiler in the file such as readme.txt, it will be easy for the people like me to learn and understand better.
Posted on 2005-06-21 05:19:45 by helloxuyihua
Awesome!
"professional gun" - this is exactly what I would love about SolASM! I've been waiting patiently for SolASM for the past year :) - hoping it'll outshine MASM as a professional's tool. I love MASM's syntax and features, it's just that I wish for some more internal powerful macros, and the ability to add such as plugins. Don't worry/bother about implementing these features, once SolASM is mature enough and I have its srccode, I can add them :)

Again, great work! Keep it up!
Once SolASM is mature, I'll do my best to make/start a SolASM32 SDK project  ;)
Posted on 2006-06-24 07:33:00 by Ultrano
The operating system seems to be progressing nicely bogdanontau
It beautifully sized for a cheap usb-mem-stick!  ;)

Are there any plans to implement the writefile api soon?
I ask because id quite like to write some apps for it but the the inability
to save any modification made is a major drawback for me.  :sad:

Keep up the good work guys.....
Posted on 2006-08-16 23:16:43 by asmrixstar

Once SolASM is mature, I'll do my best to make/start a SolASM32 SDK project  ;)

Id like to help with that if wanted/needed.
Posted on 2006-08-16 23:21:32 by asmrixstar