Index
> Non-x86 architectures > Will FasmArm ever run native on Arm ?Goto page Previous 1, 2, 3 Next |
| Author |
|
|
Tomasz Grysztar 30 Jan 2013, 19:34
hopcode wrote: because of the fact |
|||
30 Jan 2013, 19:34 |
|
|
hopcode 30 Jan 2013, 19:50
perhaps you are right, i was just thinking about that again,
but i find it hard tough considering revolution's proof. say, using mass regex on the first first versions of fasm, to make a test _________________ ⠓⠕⠏⠉⠕⠙⠑ |
|||
|
30 Jan 2013, 19:50 |
|
|
Dex4u 30 Jan 2013, 20:54
revolution wrote:
There are VM for x86 that run on the Pi, most of the raspberry pi's only have 256 of ram (now they up graded to 512). But its all about the user experience, i have not tried it, but i can see the experience not being good or easy for beginners. The big down side to ASM has always been portability, if we can get round that it would be a big plus. I think the revolution or macro ideas could work, i am going to study the source code for fasm, to get a better understanding of the problems. Thanks for everyones input. |
|||
|
30 Jan 2013, 20:54 |
|
|
revolution 30 Jan 2013, 21:19
Dex4u wrote: I think the revolution or macro ideas could work ... |
|||
|
30 Jan 2013, 21:19 |
|
|
hopcode 30 Jan 2013, 22:04
revolution wrote: I propose native code, possibly a replacement for x86_64.inc. _________________ ⠓⠕⠏⠉⠕⠙⠑ |
|||
|
30 Jan 2013, 22:04 |
|
|
revolution 30 Jan 2013, 22:18
hopcode wrote: exactly. good pointing it out. also how ? regular expression ? Starting a new project from scratch would no longer be fasmarm. It would be something else with its own set of sources (and problems). |
|||
|
30 Jan 2013, 22:18 |
|
|
Dex4u 30 Jan 2013, 23:09
revolution wrote:
I full understand your proposal, which i think it would the best way, easer to debug and read. That why i put "or" macro, which was the other way proposed. I also think your proposed (revolution), would be a good reference for coders who are learning Arm asm, that have already know x86 asm, as they can see the translation . |
|||
|
30 Jan 2013, 23:09 |
|
|
hopcode 31 Jan 2013, 00:27
revolution wrote: Native x86 code to convert x86 source into ARM binaries Code: mov eax,ecx mov r0,r1 ;easy! use regular expression to substitute all that can be substituted. you find the first line then substitute it with the second line in the source (suggested) or you do it in the binary with the binary of it ! trivial, up to that line ! in both case fasm copyright must be there, because the original layout is from Tomasz. _________________ ⠓⠕⠏⠉⠕⠙⠑ |
|||
|
31 Jan 2013, 00:27 |
|
|
revolution 31 Jan 2013, 02:13
hopcode: What I was envisaging was like this in the x86_64.inc file:
Code: ;... mov_instruction: ;... mov_reg_reg: lods byte [esi] ;read x86 reg1 movzx ebx,al shl ebx,12 lods byte [esi] cmp al,',' jne invalid_operand lods byte [esi] ;read x86 reg2 movzx eax,al lea eax,[ebx+eax+0xe1a00000] ;make ARM instruction jmp store_instruction ;... |
|||
|
31 Jan 2013, 02:13 |
|
|
hopcode 31 Jan 2013, 03:57
i see now, and still more difficoult this other way, because code
before and after final LEA must be aware of all the flags,IT,interworking etc that are unknown on x86. what you get actually from that ? 1) you will throw away the work on fasmarm 2) we will get yet another x86 tool (continuing flashing stuff on board via USB) 3) this time huge effort, no doubt. clue 1: code density on ARM is high but constant. on x86 is variable. this should be the clue to avoid that integration in the x86 code (lea eax,[ebx+eax+0xe1a00000]). all the variable density of x86 must converge to the constant density of ARM. clue 2: the 3 variants of the MOV on the ARM manual. the MOV immediate has to consider the IT the MOV register (as in your quote) should take in account registers + IT the MOV shifted must consider shifting (and eventually canonicals), this time at preprocessing! ARMv7.inc i like it, it is fine stuff, but it is the "hell"  when compared with
the linear complexity of x86_64.inc Tomasz is right when he says that fasm code, being bound to the x86, may offer some advantages. the question is the target. then, after those 2 clues i reported above, i ask: advantageous yes, but how and for what target ? now, after excluding already the macro solution one month ago in the other thread, given an adaptation of the LIBC for an ARM dev-system -your related question is the most important, imho- to alloc/dealloc memory etc,then considering the linearity of fasm surce, it would be possible to do a tanslation of all fasm source code line by line to ARM. and your role in the play would be simplified and limited to parse very few things in the ARMv7.inc. because fasm will be already ARM code there, already running on ARM. ergo, regular expressions on the first first versions of fasm to execute a test. till now, 4 different ways and no solution. but i am personally for the 3x native one. ARM runs on ARM and compiles ARM. Cheers, _________________ ⠓⠕⠏⠉⠕⠙⠑ |
|||
|
31 Jan 2013, 03:57 |
|
|
pelaillo 31 Jan 2013, 04:07
I think that a full rewrite is going to be cheaper in terms of coding and debugging.
My proposal: to start a fundrising in order to have Tomasz to devote some time to finish a set of design lineguides for fasm2. Then we can proceed as a team with the implementation under Tomasz direction, supervision and control. Our community is very small, but if we consider to widen the audience to all ARM related communities... raspberry-pi, replicant, arduino, even android developers could benefit from it. |
|||
|
31 Jan 2013, 04:07 |
|
|
revolution 31 Jan 2013, 04:21
hopcode: The x86 code does not need to know about IT and the other stuff you mention. It only needs to make a functional ARM binary that is derived from the standard x86 fasm source code. In such a situation Tomasz and myself can continue to update the x86 versions of fasm and fasmarm and the converter app can automatically produce a new binary that runs on ARM. There would not be any ARM code in the source of fasm or fasmarm. We could stay with one version of sources.
pelaillo: A full rewrite from scratch would be more time consuming and has more potential for bugs. While it is appealing to have a native ARM source version it is also a lot more work. It would be a different project and it would not be fasmarm anymore, it would be something else. An automated re-targeting-assembler only needs to be debugged once for each class of instruction, and from then on can be reused over and over to re-convert newer ARM versions directly from x86 sources. If you want to start a new project then I do fully support that and I would be keen to use it, but it wouldn't be fasmarm. |
|||
|
31 Jan 2013, 04:21 |
|
|
hopcode 31 Jan 2013, 05:22
revolution wrote: ...and the converter app can automatically produce a new binary that runs on ARM. There would not be any ARM code in the source of fasm or fasmarm   you choosed point 2) we will get yet another x86 tool (continuing flashing stuff on board via USB)
it's plain now ok, thanks, yuhuu. for the record, i just executed an analisys on the x86_64.inc resulting this quantities: Code: lines of code: 7012 (a dozen blanks) duplicated: 4778 Tomasz was right, look here encouraging imho. good morning
_________________ ⠓⠕⠏⠉⠕⠙⠑ |
|||||||||||
|
31 Jan 2013, 05:22 |
|
|
hopcode 16 Feb 2013, 04:03
Dex4u wrote: This is the ? "Will FasmArm ever run native on Arm ?" as at the moment you can not run fasmarm on device like the raspberry pi. Dex4u wrote: ...that does not come into it, but i was asking if anyones porting it or planing on porting it, as if not i will port it. hallo Dex4u, i hope you are there. can you explain me please why would you like to run something like fasmarm, native on ARM. from my point of view, i have several reasons pro, but one robust and simple contra. thank you p.s you can PM me if you like so. Cheers, _________________ ⠓⠕⠏⠉⠕⠙⠑ |
|||
|
16 Feb 2013, 04:03 |
|
|
HaHaAnonymous 16 Feb 2013, 13:42
[ Post removed by author. ]
Last edited by HaHaAnonymous on 28 Feb 2015, 21:27; edited 1 time in total |
|||
|
16 Feb 2013, 13:42 |
|
|
malpolud 16 Feb 2013, 16:36
HaHaAnonymous wrote:
Would you ever compile code on your tablet, smartphone or a special purpose machine like a CNC lathe? Even if you will develop it on such a device, compilation could be done remotely. IMO running FASMARM on an ARMed device is totally useless so far. BTW: Tell that thing to any embedded software engineer, you will be buried alive  _________________ There's nothing special about it, It's either there when you're born or not. |
|||
|
16 Feb 2013, 16:36 |
|
|
TmX 16 Feb 2013, 17:48
malpolud wrote:
Of course no. But on the other hand, major OS e.g Linux and BSD also run on ARM. Take Raspberry Pi, for example. It can be set up as a small ARM desktop. I think it would be nice if we can run FASMARM on it |
|||
|
16 Feb 2013, 17:48 |
|
|
HaHaAnonymous 16 Feb 2013, 17:55
[ Post removed by author. ]
Last edited by HaHaAnonymous on 28 Feb 2015, 21:26; edited 1 time in total |
|||
|
16 Feb 2013, 17:55 |
|
|
revolution 16 Feb 2013, 18:21
I've been burned many times and I was alive while it happened. Mostly small things like touching the soldering iron etc., but I still have the scars to prove it. Does that mean I was burned alive?
|
|||
|
16 Feb 2013, 18:21 |
|
| Goto page Previous 1, 2, 3 Next < Last Thread | Next Thread > |
Forum Rules:
|