Running fasmg on ARM v7

Index > Non-x86 architectures > Running fasmg on ARM v7

Goto page 1, 2 Next

Author

Thread

Lost_Ghost123

Joined: 12 Feb 2019
Posts: 29

Lost_Ghost123 12 Feb 2019, 09:50

Ok, let's imagine I want to have fasmg (ELF through Termux, not even mentioning APK) run on my Android. For this it has to be compiled with ARM instruction set. I don't really care about optimization or thumb mode or anything like that. fasmg itself doesn't really need optimisation, I just want to have it run. So how would I go about this? Overwrite all the CISC instructions with RISC macros? Is that possible? Do I use FASMARM or introduce my own instruction set for fasmg? Are there any guides on how to do this? Can I just copypaste 8061.inc code and redirect/overwrite half of it, will that work? Because if I will manage to compile fasmg itself for ARM v7, making it produce ARM code will be much easier. Or is there a way to make an interpreter of sorts working on top of x86 fasmg?

So, where do I start? I don't really promise anything, just something to tinker with for the summer.

Last edited by Lost_Ghost123 on 12 Feb 2019, 10:48; edited 1 time in total

12 Feb 2019, 09:50

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20337
Location: In your JS exploiting you and your system

revolution 12 Feb 2019, 10:35

I think the term you are looking for is porting.

So you want to port either fasmarm or fasmg (or both?) to run natively on the Android OS (which is using an ARM v7 CPU). Is that correct?

12 Feb 2019, 10:35

Lost_Ghost123

Joined: 12 Feb 2019
Posts: 29

Lost_Ghost123 12 Feb 2019, 10:41

Yes, exactly.

Is that how one replies? First time here...

12 Feb 2019, 10:41

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20337
Location: In your JS exploiting you and your system

revolution 12 Feb 2019, 10:49

While porting is certainly possible, it is a lot of work. And chasing down bugs would take a while. You would need to rewrite the source by hand. And if Android enables alignment checking then you would also have to make sure all hword, word and dword reads/writes are suitably aligned. And keeping up with updates would be time consuming.

But there might be a be a better option. Use an emulator. QEMU comes to mind. I don't know if that runs on Android, I haven't tried it. If not, then there is likely some other emulator that can run x86 code on Android/ARM systems. Most probably you could run the Linux version of fasmg/fasmarm. fasmarm already has the ARM instructions included. If you choose fasmg then you will also need to write the ARM macros for it.

12 Feb 2019, 10:49

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8353
Location: Kraków, Poland

Tomasz Grysztar 12 Feb 2019, 10:54

In theory you could probably write macros that would assemble x86 instructions in fasmg source into their ARM counterparts, with various caveats often leading to having to use multiple instructions to simulate a single x86 one. The result would be a terribly sub-optimal code, but it might work.

However, a good emulator may in fact end up running the original x86 code just as well if not better, if it uses dynamic recompilation. Windows on ARM should be able to run fasmg out of the box (I haven't tested it personally yet, but I see no reason why it shouldn't). I'm not sure what would be a good option for Android, though.

As for the ARM instruction set macros themselves, for now we only have aarch64 ones by tthsqe. I was hoping revolution could one day become interested in playing with fasmg macros for ARM, being probably the most competent person to do that, but I understand that there are some hurdles. I may end up writing ones myself - I even consider doing it on stream one day. It could be an interesting opportunity to show how to solve various problems when implementing an architecture from ground up using fasmg macro language.

12 Feb 2019, 10:54

Lost_Ghost123

Joined: 12 Feb 2019
Posts: 29

Lost_Ghost123 12 Feb 2019, 11:00

Yes, I know all of that, I have Limbo x86 (port of QEMU) installed. Although running an entire operating system on my poor Xiaomi would be some bad user experience. About x86->Android emulator, I didn't stumble upon it, but I will search for it specifically.

So, if I choose the porting route, questions still stand: Is 80386.inc file just the instruction set, or does it also contain inner logic of fasmg? Also, how do I make my own instruction set? I looked into the manual and here, but haven't found anything.

12 Feb 2019, 11:00

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20337
Location: In your JS exploiting you and your system

revolution 12 Feb 2019, 11:01

Tomasz Grysztar wrote:

In theory you could probably write macros that would assemble x86 instructions in fasmg source into their ARM counterparts, with various caveats often leading to having to use multiple instructions to simulate a single x86 one. The result would be a terribly sub-optimal code, but it might work.

That process is really difficult in reality. The existence of the p flag (parity) alone makes it awkward. And if you layered results from that onto the slowness of fasmg and the lower performance of the low power ARM cores ... well lets just say the speed would be glacial.

12 Feb 2019, 11:01

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20337
Location: In your JS exploiting you and your system

revolution 12 Feb 2019, 11:05

Lost_Ghost123 wrote:

Yes, I know all of that, I have Limbo x86 (port of QEMU) installed. Although running an entire operating system on my poor Xiaomi would be some bad user experience. About x86->Android emulator, I didn't stumble upon it, but I will search for it specifically.

You wouldn't need an entire OS. You could rewrite SYSTEM.INC to deal with the interfacing to QEMU using the SemiHosting interface. And then run fasmarm as a kernel module. I've done this the other way around, ARM on x86. So going the other way should be the same.

12 Feb 2019, 11:05

Lost_Ghost123

Joined: 12 Feb 2019
Posts: 29

Lost_Ghost123 12 Feb 2019, 11:06

Hi Tomasz, just wanted to say that I really enjoy your streams, keep up the good content!

But isn't having to use multiple instructions on ARM for a single x86 one the only option with CISC->RISC? I will probably have to read more into that. Also I didn't actually know what aarch64 was, will look into it right now, thanks!

12 Feb 2019, 11:06

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8353
Location: Kraków, Poland

Tomasz Grysztar 12 Feb 2019, 11:22

Lost_Ghost123 wrote:

So, if I choose the porting route, questions still stand: Is 80386.inc file just the instruction set, or does it also contain inner logic of fasmg?

80386.INC is purely an implementation of the instruction set with a syntax fully compatible with fasm 1, and nothing more. Any additions that are specifically needed for fasmg are in the SELFHOST.INC files.

Lost_Ghost123 wrote:

Also, how do I make my own instruction set? I looked into the manual and here, but haven't found anything.

In my introduction to fasmg I show several examples of how to implement new instructions and parse various kinds of syntax (with Z80 as an example architecture), though this is just a tip of an iceberg. But whenever you encounter a new problem, you can come here and ask for help.

revolution wrote:

That process is really difficult in reality. The existence of the p flag (parity) alone makes it awkward.

If this was solely for purpose of making fasmg's code run, you could at least make some assumptions about things that would have to be emulated and which ones could be skipped. Note how I already used several assumptions when adapting fasmg's code to run in long mode. Any coding conventions that make such assumptions viable need to be clearly documented in fasmg's source, though. For instance, I ended up not using the assumption that fasmg's core never uses negative offsets in 32-bit registers, because performance gain from omitting 67h prefixes was not noticeable on my machine and I preferred not having to write this down as a rule (like the rule of not touching EBP is written down).

12 Feb 2019, 11:22

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20337
Location: In your JS exploiting you and your system

revolution 12 Feb 2019, 11:52

Tomasz Grysztar wrote:

revolution wrote:
That process is really difficult in reality. The existence of the p flag (parity) alone makes it awkward.
If this was solely for purpose of making fasmg's code run, you could at least make some assumptions about things that would have to be emulated and which ones could be skipped. Note how I already used several assumptions when adapting fasmg's code to run in long mode. Any coding conventions that make such assumptions viable need to be clearly documented in fasmg's source, though. For instance, I ended up not using the assumption that fasmg's core never uses negative offsets in 32-bit registers, because performance gain from omitting 67h prefixes was not noticeable on my machine and I preferred not having to write this down as a rule (like the rule of not touching EBP is written down).

In that case it could be reasonably painless. Just a bit tedious. But there is still the issue of writing the ARM macros, which is not a trivial task. Perhaps a hybrid approach would be the answer here. Make a few modification to the fasm core (which is supporting fasmarm) to remove things like jp and other "problematic" instructions and then assemble fasmarm as an ARM binary target. Then the poster gets all the existing ARM processing code as part of the package.

12 Feb 2019, 11:52

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8353
Location: Kraków, Poland

Tomasz Grysztar 12 Feb 2019, 12:45

Even JP might not be that much problematic if used in specific context. As long as there is no label that one might jump to immediately in front of JP, it can be interpreted in conjunction with instruction that precedes it, and the parity computation can be added only in that specific place. Since x86 P flag is computed on 8 bits only, three shifts and then a bit test are enough to emulate it for purposes of JP/JNP.

12 Feb 2019, 12:45

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20337
Location: In your JS exploiting you and your system

revolution 12 Feb 2019, 13:04

If you know the exact circumstances then you can code special cases the handle them. But they only work only for that one source, and maybe only for that one version of that source, and hope nothing changes to break it in the next update. Those kinds of situations make me a bit nervous.

There is also the auxillary flag that ARM has no notion of. And anything that uses PUSHF/POPF needs to be examined to make sure the memory version of the flags is not being read or manipulated for specific bits.

Alignment problems will require extra time to solve with rewriting the source to deal with discontinuities created by adjusting memory offsets.

So it needs more than just a set of macros, it also needs a human to examine and adjust things to finalise it correctly.

12 Feb 2019, 13:04

Lost_Ghost123

Joined: 12 Feb 2019
Posts: 29

Lost_Ghost123 12 Feb 2019, 16:30

Ok, I've made a decision to write my own fasmg in C. I will try to implement all feachures from the manula and compile it for ARM. I know, the output will not be executable under ARM, but hey, it will be purely for my own education.

Now, Tomasz, Rev, are there any features that aren't included in the Tricky Stuff in Fasmg series that I have to implement or keep an eye out for?

12 Feb 2019, 16:30

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20337
Location: In your JS exploiting you and your system

revolution 12 Feb 2019, 16:46

Lost_Ghost123 wrote:

Ok, I've made a decision to write my own fasmg in C.

Sounds good. There is also the "High Level Languages" section.

Another way could be to write macros to decode the x86 source input and output equivalent ARM binary code. Then use fasmg to assemble an x86 source into ARM code. It would still need tweaking of the sources to comply with the Android OS interface, but the code in SYSTEM.INC is quite easy to adapt.

So the process could be this:

Write fasmg macros to read x86 source and output ARM binary
Tweak SYSTEM.INC for the Android interface
Run fasmg with the x86-to-ARM macros over the fasm/fasmg/fasmarm source
Run fasm/fasmg/fasmarm natively in Android and assemble something

12 Feb 2019, 16:46

guignol

Joined: 06 Dec 2008
Posts: 763

guignol 12 Feb 2019, 17:04

https://www.techcenturion.com/mediatek-helio-a22

12 Feb 2019, 17:04

guignol

Joined: 06 Dec 2008
Posts: 763

guignol 12 Feb 2019, 17:08

nativecode GUI is what's for Android

ps One thing they did not solve for android, it's hints...

_________________
qiq;

12 Feb 2019, 17:08

Lost_Ghost123

Joined: 12 Feb 2019
Posts: 29

Lost_Ghost123 12 Feb 2019, 17:23

Is that a link to a page about a processor of some kind? How is that relevant

Gui is for android, but I specifically said that I wanted fasmg to run from a termial emulator, so GUI is not needed. Or what were you trying to say, I don't get the purpose of your comment.

12 Feb 2019, 17:23

guignol

Joined: 06 Dec 2008
Posts: 763

guignol 12 Feb 2019, 17:31

Ay, the question is if revolution can make this portable mini surcompteur for 600$?

12 Feb 2019, 17:31

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8353
Location: Kraków, Poland

Tomasz Grysztar 12 Feb 2019, 17:36

Lost_Ghost123 wrote:

Now, Tomasz, Rev, are there any features that aren't included in the Tricky Stuff in Fasmg series that I have to implement or keep an eye out for?

I did my best to design and define the language separate from the specifics of implementation - I started working out implementation details after I had most of the features of language settled in a non-self-contradictory way and then I was only implementing the features that were designed. If there are any other ones, not defined in the manual, they are most likely bugs. Also, the manual has been written to be a specification of the language, not a guide to this specific implementation.

This means, that by following the manual to the letter you should be able to get compatibility at level sufficient to be able to assemble the same sources correctly, except for possible bugs. But there is another layer to it.

What the manual intentionally does not describe are the details of prediction algorithms in the code resolving process. These may vary from implementation to implementation, and the result might be that even though the same sources are resolved correctly by two assemblers, they may require a different number of passes to do so, or the optimization may end up a bit different, or in extreme case one assembler may be able to find a solution when another is not.

The specific algorithms used by my version of fasmg are such that it is able to resolve code in the same way as fasm 1, but with some additional considerations due to much more complex character of fasmg's language (like arbitrary-size linear polynomials, etc.). Their specifics are such that it would be hard to untangle them from the details of design of this specific implementation - so it is very likely that by writing another one you'd end up with at least slightly different prediction-making behavior, unless you just take my source code and meticulously rewrite it in another language, routine after routine.

12 Feb 2019, 17:36

Goto page 1, 2 Next

< 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