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.

I thought that Intel just based their architecture on ARM, but its not the same or did I get it wrong?

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

A direct link to the ARM reference is here

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

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.

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.

yup! any kind of debug infromations!

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

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.

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.

no problem, FASM is fast enough anyway, i think for anyone. and this would be worth of some slowdown

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.

Tomasz, are you going to make this official?

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.

Well, maybe at least put a link on your page, so people are aware that at least such "fork" exists.

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.

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

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

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 r0, r0, [r1, LSL #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 ...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.

so you say that it is possible to write code which would be portable among most of today's PDA, mobiles etc?