flat assembler
Message board for the users of flat assembler.

Index > Main > 32-bit FASM dead. 64-bit FASM?

Author
Thread Post new topic Reply to topic
alexfru



Joined: 23 Mar 2014
Posts: 80
alexfru 14 Apr 2018, 06:42
With 32-bit app support going away in 64-bit OSes in the coming years (e.g. no 32-bit support in Windows Subsystem for Linux, and recent Apple MacOS announcement), what's the future of FASM?
Post 14 Apr 2018, 06:42
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 14 Apr 2018, 08:05
In case of fasm 1 the problem of some Linux kernels not supporting 32-bit executables had been treated with macro tricks allowing to assemble the source of fasm 1 into an actual 64-bit executable (though still with the 4G memory limitation). The fasm.x64 has been included in the official Linux package since then.

As for the fasm g, my original intention was to make a fully featured 64-bit version by rewriting the source when a need arises. The source of fasmg is written in such way that this should not be hard to do. But there has been no strong incentive to do that, the 32-bit executables remain more universal even now (to complicate matters further, there are things like Windows 10 on ARM being able to run 32-bit x86 programs but not 64-bit ones).
Post 14 Apr 2018, 08:05
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 2519
Furs 14 Apr 2018, 13:16
Wasn't Apple going to start the switch to ARM by 2020? Since they said they will stop buying Intel chips by then. So an x86 assembler for that stupid platform doesn't seem like it will be much of a deal.
Post 14 Apr 2018, 13:16
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 15 Apr 2018, 10:43
By the way, when I wrote about this originally, I mentioned that the way fasmg is written, it should even be possible to convert its source to other architectures with not that much of a problem, not necessarily just x64. At least I believe I could do it.

An interesting possibility is converting in into ARM instructions. I still have no official macros for the ARM instruction set, but there have been others working on that.

One may wonder, when I consider adapting the fasmg sources to multiple architectures like that, why did I choose to write it in assembly at all, when writing it in C would make it so much easier? A simple answer could be that I considered self-hosting an important feature. But at the time when I was preparing the early releases of fasmg, I did not even know that self-hosting would be viable, I was afraid the self-assembly times could be much worse than what they finally turned out to be.

The main reason was that I have been programming in assembly so much in my life, that no other language comes even close. So even though I have much experience working with many different programming languages, through assembly I can express my ideas with an ease that no other language gives me, it is as if writing in assembly was akin to speaking my native language.

When one wants to write a story, they are going to write in a language that they not only can speak fluently, but the one they know so well that they can easily manipulate it to express exactly what they want to say. For me, when I create a project like fasm g, it is like writing a story. And thus I had no other choice but to write it in the language in which I am able to speak freely like in no other one. The fun of self-hosting is then just an afterthought.
Post 15 Apr 2018, 10:43
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 21 Apr 2018, 19:47
I have just realized that even though fasmg requires "malloc", it is possible to use the aforementioned trick I used for fasm 1 to reassemble fasmg as a long mode code but use x32 ABI where pointers are 32-bit anyway. As long as some libc for x32 would be available, this should work. And it would require little to no work, I should definitely give it a try.
Post 21 Apr 2018, 19:47
View user's profile Send private message Visit poster's website Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo 23 Apr 2018, 06:17
Tomasz Grysztar wrote:

One may wonder, when I consider adapting the fasmg sources to multiple architectures like that, why did I choose to write it in assembly at all, when writing it in C would make it so much easier? A simple answer could be that I considered self-hosting an important feature. But at the time when I was preparing the early releases of fasmg, I did not even know that self-hosting would be viable, I was afraid the self-assembly times could be much worse than what they finally turned out to be.


A full re-implementation might be overkill. A suitable subset is often easier. It's an incorrect assumption that you need to support every single feature just to bootstrap (obviously?).

P4 Pascal didn't support the full language, but it can bootstrap (more or less, has a few bugs, IIRC). I've even seen adaptations of Pascal-S (even smaller subset) that are self-compiling (well, byte-compiling). Even Oberon is "almost" considered a subset of Modula-2 (since it threw away a lot but added only a very few useful features).

Tomasz Grysztar wrote:

The main reason was that I have been programming in assembly so much in my life, that no other language comes even close. So even though I have much experience working with many different programming languages, through assembly I can express my ideas with an ease that no other language gives me, it is as if writing in assembly was akin to speaking my native language.


Well, you might know more than one "native" language, even several of varying degrees of competency. The choice of which to use often depends on target audience. We like to pretend that we always choose the best tool for the job (simplest, most efficient, most portable), but often it's just habit, muscle memory, personal preference, etc.

Tomasz Grysztar wrote:

When one wants to write a story, they are going to write in a language that they not only can speak fluently, but the one they know so well that they can easily manipulate it to express exactly what they want to say.


But you are writing this in English. Is English your native language? Do you have native competency there? (Presumably no and yes, respectively. I'm just making a weak point.) Maybe you truly do feel more comfortable in English, but more likely you're reacting to the popular English-speaking audience rather than personal preference, flexibility, comfort, etc.

Esperanto users are horrible about neologisms (tons of non-UV words wantonly used). It never stopped most of them from trying anyways! Most people don't carry full dictionaries around with them (and certainly they can't memorize, or don't care about, "official" vocabularies. Yeah yeah, living language, but it needs a solid foundation! You can't change literally everything and expect stability.)

Pewdiepie is a very popular Swedish Youtuber, but he always communicates in English. He's what I would call native competency (probably taught such in schools plus lots of practice). His girlfriend is Italian, and they exclusively communicate in English (obviously??). Sure, he could make videos in Swedish, but I think he attracts a much wider audience, by far, by using English. (Note that I'm am not encouraging English superiority at all, just stating facts. Even now, many viewers demand subtitles.)

If I moved to France, it would "probably" make little sense for me to prefer my native language instead of French, overall. It makes no sense to be comfortable and flexible if nobody can understand me. But that's my burden, not theirs.

Tomasz Grysztar wrote:

For me, when I create a project like fasm g, it is like writing a story. And thus I had no other choice but to write it in the language in which I am able to speak freely like in no other one. The fun of self-hosting is then just an afterthought.


It's possible to target a strict subset (which is more or less what E-o is, at least UV from Fundamento) and still make do with it. Ultra simple is still often effective. In fact, I believe that's (roughly) the definition of "elegant".

I haven't checked lately, but IIRC, your FASM sources are macro free and no more than pure i386 code. Thus, no i686, no SIMD, nothing further. That alone is a strict subset, albeit popular, which you technically aren't forced to limit yourself to. I'm sure it could be "reduced" further!

(I know you know all of this better than I do, but I'm just rambling.)
Post 23 Apr 2018, 06:17
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 23 Apr 2018, 07:14
rugxulo wrote:
A full re-implementation might be overkill. A suitable subset is often easier.
What I hinted at is not a re-implementation but more or less straightforward translation. I consider it much easier than re-implementing even a small subset from scratch. As I already wrote in that original thread, I have consciously used a very simple set of instructions to make it easier for myself to convert it to different architectures (and as a bonus it can still run on an old 386 machine). One could say it was also part of my "artistic vision".

And as the adaptation of fasm's code to long mode demonstrates, to some extent it is even possible to automate such translations. No perfect automation is possible in case of fasm[g] though, I would have to add a layer of syntactic quirks to the source to make that possible. Though perhaps that would be a good way to do it.

rugxulo wrote:
Well, you might know more than one "native" language, even several of varying degrees of competency. The choice of which to use often depends on target audience. We like to pretend that we always choose the best tool for the job (simplest, most efficient, most portable), but often it's just habit, muscle memory, personal preference, etc.
Yes, it's personal preference. Is it not what I have written above? Smile It is that in assembly I am relatively easily able to write something that fulfills my vision and that I am later comfortable with looking at. Someone else may not see a difference and/or not care, but I do.
Post 23 Apr 2018, 07:14
View user's profile Send private message Visit poster's website Reply with quote
vivik



Joined: 29 Oct 2016
Posts: 671
vivik 29 Apr 2018, 09:04
will wine still work? Will older games still work?
Post 29 Apr 2018, 09:04
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 2519
Furs 29 Apr 2018, 12:29
Wine, in its current state, won't work (the 32-bit side of course). Not sure if Crossover have any plans to deal with this (since Mac is their main market, unfortunately). That's my only gripe with it, because Crossover are the main contributors to Wine. And Wine has to be my most favorite open source application (Linux kernel doesn't count since it's a kernel). But I hate Apple.

Obviously after Apple switch to ARM, no x86-based application will work without an emulator... even if Wine gets ported, the games or applications it has to run will still be x86, so what's the point?
Post 29 Apr 2018, 12:29
View user's profile Send private message Reply with quote
Melissa



Joined: 12 Apr 2012
Posts: 125
Melissa 03 May 2018, 04:27
Tomasz Grysztar wrote:
I have just realized that even though fasmg requires "malloc", it is possible to use the aforementioned trick I used for fasm 1 to reassemble fasmg as a long mode code but use x32 ABI where pointers are 32-bit anyway. As long as some libc for x32 would be available, this should work. And it would require little to no work, I should definitely give it a try.


Speaking of x32, when will fasm support that format? Wink nasm supports it since beginning...
Post 03 May 2018, 04:27
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 03 May 2018, 07:52
Melissa wrote:
Speaking of x32, when will fasm support that format? Wink nasm supports it since beginning...
Similarly to Mach-O this is something that is supported by fasmg with no specific plans of backporting. Everything is so much easier with fasmg...

Some time ago I have made a few x32 examples for fasmg but they are not yet published anywhere. If you'd like I may share them here.
Post 03 May 2018, 07:52
View user's profile Send private message Visit poster's website Reply with quote
Melissa



Joined: 12 Apr 2012
Posts: 125
Melissa 03 May 2018, 13:14
Tomasz Grysztar wrote:
Melissa wrote:
Speaking of x32, when will fasm support that format? Wink nasm supports it since beginning...
Similarly to Mach-O this is something that is supported by fasmg with no specific plans of backporting. Everything is so much easier with fasmg...

Some time ago I have made a few x32 examples for fasmg but they are not yet published anywhere. If you'd like I may share them here.


Ok, I'll start to learn fasmg then Wink

edit: I can't manage this. Documenation is parse regarding making custom formats
and I haven't compiled even hello.asm on Linux because include is not found. no go ;(
Post 03 May 2018, 13:14
View user's profile Send private message Reply with quote
Melissa



Joined: 12 Apr 2012
Posts: 125
Melissa 04 May 2018, 23:08
Please share x32 examples. I figured out how to make executable s from forum post, but I don't know how to make x32 object files, yet.
Post 04 May 2018, 23:08
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 05 May 2018, 10:19
Melissa wrote:
Please share x32 examples. I figured out how to make executable s from forum post, but I don't know how to make x32 object files, yet.
I can prepare some example objects, though I have not yet had a chance to really test them. The Linux machines that are currently available to me have GCC/LD with no "-mx32" capability.

I am able to run syscall-only x32 executables, since kernel support is enough for them to run. The dynamically linked ones I could also not test, they require "/libx32/ld-linux-x32.so.2" to be present. Do you have it on your system?
Post 05 May 2018, 10:19
View user's profile Send private message Visit poster's website Reply with quote
Melissa



Joined: 12 Apr 2012
Posts: 125
Melissa 05 May 2018, 12:33
Unfortunately not, I have to compile kernel in order to run x32 executables at all ;(
but I can link with ld and make static executables. None gcc x32 libs whatsoever.
Post 05 May 2018, 12:33
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 05 May 2018, 13:43
OK, so I'm not going to pursue libx32 linking at the moment.

Here's a package with an example executable and two objects I made. Please try linking both objects together with "ld -mx32" and see if it works.

To get the examples to assemble you need to include the FORMAT.INC macros. I put all the required files in the "include" directory, they are the same as in the Windows headers package for fasmg. You can assemble the examples with commands looking like:
Code:
fasmg -iInclude\ \'include/format/format.inc\' hello_x32.asm 
fasmg -iInclude\ \'include/format/format.inc\' obj1.asm      
fasmg -iInclude\ \'include/format/format.inc\' obj2.asm    


Description: Basic x32 examples for fasmg (untested)
Download
Filename: x32.tgz
Filesize: 72.75 KB
Downloaded: 969 Time(s)

Post 05 May 2018, 13:43
View user's profile Send private message Visit poster's website Reply with quote
Melissa



Joined: 12 Apr 2012
Posts: 125
Melissa 05 May 2018, 15:15
Yeeeeeeeeeee, it works beautifully!

Thanks!
Post 05 May 2018, 15:15
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
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


Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.