about FASM

[BogdanOntanu]

I've tested Sol_Asm on my SUSE linux and it works really well ! I was able to compile SOL_ASM and the native code example.

Good to know. Thanks for testing and reporting this. Sol_ASM should be able to run on all UNIX like systems that have a libC available.
BTW that should also be true for FASM :D

I wasn't able to compile the libc example for some reason, I might be missing a dependency...
:bg.

I wonder what that dependency could be... ? (maybe _exit ?)
After all if you have been able to build SOL_ASM then the sample should also work... maybe I made a mistake in the sample.

I really wonder how can you achieve this portability, you're not even using libc on Windows !!!!! I see you using WriteFile, ReadFile, globalalloc but when you're on Linux what happens ?

That is quite simple.
1) I use a minimal set of functions from OS.
==============================
I have a habit to have a very low OS dependency on all of my projects. You might notice that I use my own sprintf function and avoid the libC or Win32 API.

2) There is a portability layer in SOL_ASM.
=============================
Sol_ASM was designed to run on multiple OSes right from day one (on WIn32 and SOL_OS)
All OS dependent functions are going through a wrapper that adapts the parameters and API to the targets OS.
All my code uses my functions with my parameters and my calling conventions.
This way the only place to change anything is in the wrapper functions. No line of code is changed in the Sol_ASM core when I build for another target OS.

3) #ifdef handles OS target inside wrapper functions
==================================
Something like this

Code Select Expand


#ifdef WIN32
  ... memory alloc function for WIN32
#endif

#ifdef OS_LIBC
  ... memory alloc function for libC
#endif


In fact Hawk ported Sol_ASM on his MAC OSX in a few hours by changing only those functions while learning the Mac OSX calling conventions and stack alignment requirements and without changing anything from SOL_ASM core.

Of course that this portability is made easy by the widespread use of the Intel CPU and the nature of command line like applications because the number of functions to be wrapped are limited: GetCommandLIne, OpenFIle, ReadFile, WriteFile, CloseFile, Memory_Alloc, Memory_Free, WriteToConsole

I am now in the process of making such a system for GUI applications also. This would allow the very same GUI application to run on Windows, Solar_OS, Unix, Mac OSX

However this thread deviates too much from it's original "about FASM" title :D

[PBrennick]

Bogdan,
I do not want to deviate from the purpose of this thread but felt I need to comment on a couple of things...

All OS dependent functions are going through a wrapper that adapts the parameters and API to the targets OS.

I am now in the process of making such a system for GUI applications also. This would allow the very same GUI application to run on Windows, Solar_OS, Unix, Mac OSX

I can only guess at the complexity of those issues. This is truly amazing to me. I can think of no other assembler that even comes close to this. Kudos!  :U

Paul

[mitchi]

I've tested Sol_Asm on my SUSE linux and it works really well ! I was able to compile SOL_ASM and the native code example.

Good to know. Thanks for testing and reporting this. Sol_ASM should be able to run on all UNIX like systems that have a libC available.
BTW that should also be true for FASM :D

I wasn't able to compile the libc example for some reason, I might be missing a dependency...
:bg.

I wonder what that dependency could be... ? (maybe _exit ?)
After all if you have been able to build SOL_ASM then the sample should also work... maybe I made a mistake in the sample.

I really wonder how can you achieve this portability, you're not even using libc on Windows !!!!! I see you using WriteFile, ReadFile, globalalloc but when you're on Linux what happens ?

That is quite simple.
1) I use a minimal set of functions from OS.
==============================
I have a habit to have a very low OS dependency on all of my projects. You might notice that I use my own sprintf function and avoid the libC or Win32 API.

2) There is a portability layer in SOL_ASM.
=============================
Sol_ASM was designed to run on multiple OSes right from day one (on WIn32 and SOL_OS)
All OS dependent functions are going through a wrapper that adapts the parameters and API to the targets OS.
All my code uses my functions with my parameters and my calling conventions.
This way the only place to change anything is in the wrapper functions. No line of code is changed in the Sol_ASM core when I build for another target OS.

3) #ifdef handles OS target inside wrapper functions
==================================
Something like this

Code Select Expand


#ifdef WIN32
  ... memory alloc function for WIN32
#endif

#ifdef OS_LIBC
  ... memory alloc function for libC
#endif


In fact Hawk ported Sol_ASM on his MAC OSX in a few hours by changing only those functions while learning the Mac OSX calling conventions and stack alignment requirements and without changing anything from SOL_ASM core.

Of course that this portability is made easy by the widespread use of the Intel CPU and the nature of command line like applications because the number of functions to be wrapped are limited: GetCommandLIne, OpenFIle, ReadFile, WriteFile, CloseFile, Memory_Alloc, Memory_Free, WriteToConsole

I am now in the process of making such a system for GUI applications also. This would allow the very same GUI application to run on Windows, Solar_OS, Unix, Mac OSX

However this thread deviates too much from it's original "about FASM" title :D

So that's how it works. You're really amazing you know ! ;)

[GregL]

I had the best luck writing asm programs for Linux (Ubuntu) with as, also known as Gas, the GNU Assembler.