flat assembler
Message board for the users of flat assembler.
 Home   FAQ   Search   Register 
 Profile   Log in to check your private messages   Log in 
flat assembler > Non-x86 architectures > FASMARM v1.42 - Cross assembler for ARM CPUs

Goto page Previous  1, 2, 3, ... 27, 28, 29  Next
Author
Thread Post new topic Reply to topic
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15085
Location: Opcode space
Zhak asked about

Quote:
(for example, vga programming)?

While the xScale based PDA's will all have similar internal instruction sets for the processor you probably won't know what external bits each manufacturer has put around it to make the PDA complete unless you open it to look. Also the OS probably won't allow you low-level access so then you will have to replace the OS with your own.
Post 04 Oct 2005, 12:22
View user's profile Send private message Visit poster's website Reply with quote
Madis731



Joined: 25 Sep 2003
Posts: 2146
Location: Estonia
I thought that Intel just based their architecture on ARM, but its not the same or did I get it wrong?
Post 05 Oct 2005, 08:25
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15085
Location: Opcode space

Quote:
I thought that Intel just based their architecture on ARM

As afar as I am aware Intel use the ARM instruction set v5TE. All the peripherals and memory maps etc. are unique to each manufacturer, ARM do not specify the hardware part. Just the code set is the same (or at least similar).
Post 05 Oct 2005, 10:03
View user's profile Send private message Visit poster's website Reply with quote
ronware



Joined: 08 Jan 2004
Posts: 179
Location: Israel
A direct link to the ARM reference is here
Post 07 Oct 2005, 16:29
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15085
Location: Opcode space
I have updated the attachment at the top of this thread. It fixes a bug that would cause problems in constructs like this:

Code:
if 0
str r1,[r2,r3]
end if

Post 20 Oct 2005, 01:16
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15085
Location: Opcode space
I have uploaded version 1.04 at the top of this thread.

One bug fixed with code classification when using TIMES:

Code:
times 4 nop ;was previously tagged at data

And improved the embedded line number information for smaller size.
Post 10 Nov 2005, 03:58
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6508
Location: Kraków, Poland
I myself consider designing some dedicated parser for the syntaxes like ARM, so fasm could be adopted to use the original syntax of that architecture.
I'm also working now (though only in design area at the moment) on the new line of fasm's core (will become 1.65.x when ready) that will support in much better way (and without a not-fully-reliable tricks like the one used by my listing extension) exporting any kind of debug information or listings. This, to be truly well working and reliable, needs some important changes in all the basic internal structures used by fasm, so it might still take some time for me to finish it.
Post 10 Nov 2005, 11:26
View user's profile Send private message Visit poster's website Reply with quote
MazeGen



Joined: 06 Oct 2003
Posts: 953
Location: Czechoslovakia
yup! any kind of debug infromations! Smile
Post 10 Nov 2005, 12:28
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15085
Location: Opcode space
I have used some very ugly patches to make the ARM code parser work properly. For the most part it does parse the standard ARM syntax with the exception of the # to indicate literal values and labels starting with digits. But in my opinion the way ARM use the hash is entirely unnecessary and verbose. The other thing that I find rather stupid with ARM syntax is forcing all labels to start on column 1 and not allowing any instructions to start on column 1. I feel more comfortable using FASMARM over the ARM ADS (but my opinion may be biased Wink ).

I used the listing code as my template to generate the labels, line numbers and code classification information. This means there are always three extra passes for the ELF DWARF format. For my current projects this usually means doubling from 3 to 6 passes (about 10 seconds now becomes 20 seconds) to assemble (but still much faster than ADS). If there is a way to improve this process then that would be a very good thing.
Post 11 Nov 2005, 01:30
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6508
Location: Kraków, Poland
Yes, and actually any additional passes should be avoided - after the code got resolved, doing one more pass might be risky, as for example %t symbol might get different value, and thus possibly - in such rare cases that generated code would be dependent on %t value - the additional passes would not exactly repeat the already-successfully-resolved code. That's why I'm designing an other way to gather such information - though, on the other hand, it will slow down the required passes a bit.
Post 11 Nov 2005, 01:59
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7109
Location: Slovakia
no problem, FASM is fast enough anyway, i think for anyone. and this would be worth of some slowdown
Post 11 Nov 2005, 09:16
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15085
Location: Opcode space

Quote:
actually any additional passes should be avoided

I see a simple way to avoid the %t problem mentioned above is to call the time only once at startup and just use that time throughout the assembly process. Of course this can mean the time used in the code may be 10 or 20 seconds (for big projects) earlier than the finish time, but I don't think that is an important thing to worry about.

However, that aside, I do see the point that you are making about the extra passes and agree that avoiding them is a good thing.
Post 11 Nov 2005, 16:37
View user's profile Send private message Visit poster's website Reply with quote
comrade



Joined: 16 Jun 2003
Posts: 1109
Location: Russian Federation
Tomasz, are you going to make this official?
Post 21 Jan 2006, 19:25
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6508
Location: Kraków, Poland
I'd prefer it to be a "fork", separate project - the changes I'm going to apply (or already applied) to the fasm's core may not agree with what is used here.
Also separating it from "regular" fasm would allow adapting parser and preprocessor more to the needs of ARM syntax - something I would strongly recommend.

On the other hand it would be better to make such forks after I finish the core changes for 1.65 line - since some of them are going to make easier collecting the various information about symbols etc.
Post 21 Jan 2006, 19:33
View user's profile Send private message Visit poster's website Reply with quote
comrade



Joined: 16 Jun 2003
Posts: 1109
Location: Russian Federation
Well, maybe at least put a link on your page, so people are aware that at least such "fork" exists.
Post 21 Jan 2006, 21:16
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6508
Location: Kraków, Poland
This is the wider problem, why don't I maintain any official links page on my website. It's mainly because I'm afraid of it getting not up-to-date quickly, while the message board can provide the huge collections of links where anyone can put own addition or update at any time.
Post 23 Jan 2006, 12:33
View user's profile Send private message Visit poster's website Reply with quote
Kuemmel



Joined: 30 Jan 2006
Posts: 193
Location: Stuttgart, Germany
Hi guys,

I recently discovered FASM to get into learning x86 assembler...but before I only coded in ARM assembly language for years on my Desktop Acorn Risc PC, with an ARM610, later equipped with an StrongARM, the precessor of the Intel XSCale developed by DEC.

A decade before there was a nice book about assembly programming called "Archimedes Assembly Language" by Mike Ginns...I remember that it is now available for free on the net somewhere.

There's also a relatively new still supported Desktp Computer running an 600 MHz XScale: http://www.iyonix.com/

...just for you information and to do a little bit of advertising for a wonderfull programmable CPU (except floating point...). If you wanna know more or need other help regarding the assembly programming tell me...
Post 07 Feb 2006, 21:27
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7109
Location: Slovakia
Kuemmel: well, somebody who seems experienced with ARM? Is it really useful to code it in assembly? Eg. isn't there different processor "in each" mobile phone? How much do the processors differ?
And what about instruction possibilities? Is it real hardcore RISC, with only basic things (eg. harder to code by hand)?

Maybe you could link some ARM code examples...
Post 08 Feb 2006, 01:21
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Kuemmel



Joined: 30 Jan 2006
Posts: 193
Location: Stuttgart, Germany
Hi vid,

yep, basically it's true, the cpu's vary a lot in all these devices (PDA, phone, etc.), but they are all based on the same architecture. Normally all these companies license the architecture/design from ARM (www.arm.com) and then build the cpu's as ARM themselves doesn't produce any hardware themselves.

These architectures have a great variety and are enhanced all the time, but normally within some limits the compatibility is there. Before long time (ARM600) for example there was a 26bit-mode, nowdays the XScale only supported 32bit-mode, so when you go to far back in ARM-history there are some differences. ARM themselves number the architecture, so the XScale is based on ARMv5TE-architecture, where 5 means the evolution number and T is for an added 'Thumb'-instruction core (16 bit sized instruction to save memory) and E for a kind of DSP-like MMX extention.

Recently there are more things added to the core, like SIMD instructions, or a JAZCELL, supporting JAVA byte code...
http://www.arm.com/products/CPUs/architecture.html
...but of course you always have to look, what the cpu-producing company (Intel, Samsung,...) is actually using of these offers from ARM...

I mainly coded on my Risc PC, using the core 26/32 bit cpu, that code is I think valid for all the later CPU's, except the 26-bit thing...the first thing to know that all instructions have a length of 32-bit (in ARM coding 32-bit was always related to 1 word, not like DWORD in x86 coding, as ARM was always 32-bit RISC).

What I like most is the following stuff of it:

- 16 registers (0 to 12 general purpose, R13 stackpointer, R14 Linkregister, R15 program counter)
- extensive use of conditioned execution on all commands (not only mov) ike:

Code:

cmp   r0, #10
movgt r0, #0
movle r0, #1



- doing multiple stuff with one instruction like:

Code:

add r0r0, [r1LSL #5]



...what means r0=r0 + (r1<<5).

and storing/loading multiple words:

Code:

stmia r0!,{r1-r8}



...this one stores r1 to r8 (8*32 bit data) at r0 and after storing (IA) increments the address (r0), so that you can easily do a memory copy loop without the need of an add r0,r0,#256.

The instruction set is really RISC-like limited, but actually I never felt limited, except of the missing FPU, even the missing DIV can be worked around normally with MUL by 1/x. The XScale/StrongARM has also the extension of a 64bit-MUL.

Downside of the CPU's:
- No FPU (except the new multimedia extensions)
- No DIV instruction
- Memory/Video Memory access slow compared to general desktop x86 architecture
- No second level cache

All this is only as far as I know...the ARM world is big Wink ...it's the most sold 32bit-CPU on the world (think of all the Advance/DS Nintendo Gamboys). Sometimes I've seen demo-coding for the gameboy, but I don't know about their developement tools, fur sure ARM company itself has lots of may be commercial tools.

When it comes to OS-coding may be it get's difficult to get hand on a decent tool or information for all the mobile phones...don't got any experience with other OS than the Risc OS 4.
Post 08 Feb 2006, 09:34
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7109
Location: Slovakia
so you say that it is possible to write code which would be portable among most of today's PDA, mobiles etc?
Post 08 Feb 2006, 10:39
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2, 3, ... 27, 28, 29  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


Powered by phpBB © 2001-2005 phpBB Group.

Main index   Download   Documentation   Examples   Message board
Copyright © 2004-2016, Tomasz Grysztar.