flat assembler
Message board for the users of flat assembler.
Index
> Main > 32-bit FASM dead. 64-bit FASM? |
Author |
|
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). |
|||
14 Apr 2018, 08:05 |
|
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.
|
|||
14 Apr 2018, 13:16 |
|
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. |
|||
15 Apr 2018, 10:43 |
|
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.
|
|||
21 Apr 2018, 19:47 |
|
rugxulo 23 Apr 2018, 06:17
Tomasz Grysztar wrote:
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:
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:
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:
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.) |
|||
23 Apr 2018, 06:17 |
|
Tomasz Grysztar 23 Apr 2018, 07:14
rugxulo wrote: A full re-implementation might be overkill. A suitable subset is often easier. 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. |
|||
23 Apr 2018, 07:14 |
|
vivik 29 Apr 2018, 09:04
will wine still work? Will older games still work?
|
|||
29 Apr 2018, 09:04 |
|
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? |
|||
29 Apr 2018, 12:29 |
|
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? nasm supports it since beginning... |
|||
03 May 2018, 04:27 |
|
Tomasz Grysztar 03 May 2018, 07:52
Melissa wrote: Speaking of x32, when will fasm support that format? nasm supports it since beginning... 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. |
|||
03 May 2018, 07:52 |
|
Melissa 03 May 2018, 13:14
Tomasz Grysztar wrote:
Ok, I'll start to learn fasmg then 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 ;( |
|||
03 May 2018, 13:14 |
|
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.
|
|||
04 May 2018, 23:08 |
|
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 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? |
|||
05 May 2018, 10:19 |
|
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. |
|||
05 May 2018, 12:33 |
|
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
|
|||||||||||
05 May 2018, 13:43 |
|
Melissa 05 May 2018, 15:15
Yeeeeeeeeeee, it works beautifully!
Thanks! |
|||
05 May 2018, 15:15 |
|
< Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.