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).

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.

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.

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.

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.)

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? 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.

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?

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? nasm supports it since beginning...

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?

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:

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum