|
Author |
Thread |
 |
|
jazz
Joined: 16 Jul 2016
Posts: 47
|
Portable server applications in FASM, does it make sense?
For various reasons I'm planning to implement a TCP server application in either FPC, COBOL or (F)ASM (one of which being me trying to learn as many programming languages as possible and I still don't have enough experiences with either of them). While (F)ASM seems to be the most sophisticated (i.e. most interesting) and performance-winning of my three choices, I wonder if it wouldn't be incredibly stupid to use it, given that server applications should be portable (there are too many platforms and too many operating systems around).
While using TCP shouldn't differ much, I'd still need file/directory listing capabilities. Using SysCalls would probably tie my application to a very limited selection of operating systems. Is this one of the "better don't use ASM" situations or am I missing something relevant?
_________________ invoke Beer
|
19 Aug 2016, 11:52 |
|
revolution
When all else fails, read the source
Joined: 24 Aug 2004
Posts: 15643
Location: Thasus
|
There are two types of portability.
1) portable across OSes
2) portable across CPUs
Assembly can give you 1) in just the same way that HLL can give you 1) i.e. it requires a lot of work and patience.
Assembly won't give you 2), you will need to rewrite for each new CPU architecture.
|
19 Aug 2016, 12:49 |
|
jazz
Joined: 16 Jul 2016
Posts: 47
|
1) But, while HLLs provide some levels of abstraction over filesystem (and similar) APIs, ASM doesn't (AFAICS), hence my question. For some of the most interesting things I can't really find a way to circumvent OS differences. Could be just me and my limited experience...?
2) I can perfectly live with being "amd64-only", as this is probably the architecture that is most relevant on the hardware I'm targeting.
|
19 Aug 2016, 12:58 |
|
revolution
When all else fails, read the source
Joined: 24 Aug 2004
Posts: 15643
Location: Thasus
|
jazz wrote: |
1) But, while HLLs provide some levels of abstraction over filesystem (and similar) APIs, ASM doesn't (AFAICS), hence my question. For some of the most interesting things I can't really find a way to circumvent OS differences. Could be just me and my limited experience...?
|
|
In assembly you can also use MSVCRT if you desire. Perhaps that is "cheating" though, I don't know. But if you want to avoid MSVCRT then you can write the OS interface code manually, it is actually a not-too-onerous task.
|
19 Aug 2016, 13:06 |
|
jazz
Joined: 16 Jul 2016
Posts: 47
|
Is there a way to write an OS-independent file listing function with "if this is a Linux, do the following, if it's Windows, do this, ..." in FASM?
|
19 Aug 2016, 13:34 |
|
revolution
When all else fails, read the source
Joined: 24 Aug 2004
Posts: 15643
Location: Thasus
|
jazz wrote: |
Is there a way to write an OS-independent file listing function with "if this is a Linux, do the following, if it's Windows, do this, ..." in FASM?
|
|
Yes, of course. It is assembly, we can do whatever we want.
Code: |
ShowMeTheGoddamnedFiles:
if LINUX
;...
int 0x80
else if WINDOWS
;...
invoke SomeThing,...
end if
ret
|
|
|
19 Aug 2016, 13:45 |
|
jazz
Joined: 16 Jul 2016
Posts: 47
|
That's neat. FASM is still in the game then.
Thank you a lot!
|
19 Aug 2016, 14:10 |
|
JohnFound
Joined: 16 Jun 2003
Posts: 3464
Location: Bulgaria
|
jazz wrote: |
Is there a way to write an OS-independent file listing function with "if this is a Linux, do the following, if it's Windows, do this, ..." in FASM?
|
|
Also, you can check FreshLib - it is part of the project Fresh IDE and is created as portable library for OS independent development. Recently all my FASM software is created using FreshLib and is portable across at least Windows and Linux.
The GUI part of the library is still not finished and not suitable for production, but non-gui part is pretty stable and mature.
FreshLib for this very moment supports Linux, Windows and partially KolibriOS.
The only problem can be the relatively bad documentation, but there are some examples and I can provide some help.
The source code is in the fossil repository: here
_________________ Tox ID: 48C0321ADDB2FE5F644BB5E3D58B0D58C35E5BCBC81D7CD333633FEDF1047914A534256478D9
|
20 Aug 2016, 13:23 |
|
jazz
Joined: 16 Jul 2016
Posts: 47
|
I'd love to (and Fresh IDE is my IDE of choice), but "Linux and Windows" is not good enough. I own Unix servers. 
|
20 Aug 2016, 14:10 |
|
JohnFound
Joined: 16 Jun 2003
Posts: 3464
Location: Bulgaria
|
jazz wrote: |
I'd love to (and Fresh IDE is my IDE of choice), but "Linux and Windows" is not good enough. I own Unix servers.
|
|
The OS dependent layer of FreshLib is very thin and can be easily ported to Unix (BSD?) using the Linux code as a template. This way, FreshLib will have one more OS supported and you will have your portable code. Win - win. 
_________________ Tox ID: 48C0321ADDB2FE5F644BB5E3D58B0D58C35E5BCBC81D7CD333633FEDF1047914A534256478D9
|
22 Aug 2016, 15:51 |
|
jazz
Joined: 16 Jul 2016
Posts: 47
|
That's inviting. Now I'm somewhat curious. I'm just afraid that I won't come really far. Porting Freshlib with my current experience in ASM (exactly 0 written "real world" LoC) sounds rather sophisticated.
Damn.
_________________ invoke Beer
|
22 Aug 2016, 17:18 |
|
TheRaven
Joined: 22 Apr 2008
Posts: 87
Location: U.S.A.
|
FAsm.o for UNIX will compile most easily with CLang and inline assembler is easy as pie in FPC. Have used FAsm to develop assembler code and only had to copy and past into an FPC ASM block. Just use standard Asm and all is good, but you will undoubtedly already know this. I use Lazarus IDE to wrap a GUI around my code and FPC supports direct memory access for data members from assembler blocks so it rocks.
I use FPC and Lazarus IDE for HLL and FAsm for LLL and everything works well at the x86 level. x86_64 FPC has RIP issues currently so I have regressed to x86 with FPC until such time as FPC goes native 64bit.
As you probably already know Jazz, FreeBSD has gone full support for x86_64, so 32 bit systems in a 64 bit environment is totally possible now.
FAsm and FPC are a match made in heaven as far as UNIX systems are concerned --I could not be more pleased with the pairing. 
|
19 Nov 2016, 20:29 |
|
jazz
Joined: 16 Jul 2016
Posts: 47
|
Lazarus is nice. When I was young, I was a Pascal programmer, but I can't imagine why I would prefer it to C/C++ these days. Except for GUI applications where it really shines.
Yes, I somewhat follow the FreeBSD development. Not too bad.
|
20 Nov 2016, 03:00 |
|
rugxulo
Joined: 09 Aug 2005
Posts: 2239
Location: Usono (aka, USA)
|
jazz wrote: |
Lazarus is nice. When I was young, I was a Pascal programmer, but I can't imagine why I would prefer it to C/C++ these days.
|
|
Although I'm far from expert ....
Choosing FPC over C is a very obvious choice given many advantages. However, of course C++ overcomplicates everything. A quick check shows that C++17 still doesn't have proper modules. Not to mention smartlinking (which admittedly is already somewhat supported in GCC with ELF targets), which is always nice.
Granted, if you're already heavily invested in C++, already work on big projects, have no major complaints, lack time (or interest) to waste to learn "yet another" way to do the same ol' boring stuff, it's probably less important.
Is FPC "better" than C? Almost definitely. (Yes, I know everybody says stupid things like that. C isn't bad by any stretch, but ....)
Is FPC "better" than ultra-modern C++? Probably not, but I presume it's at least (roughly) equal.
I would definitely recommend giving it a look, if curious.
|
20 Nov 2016, 10:10 |
|
|
|
Forum Rules:
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You can download files in this forum
|
|
|
|
|
|
|
|
|