There have been efforts in the past to allow running of ARM Linux
binaries directly under RISC OS, and it worked after a fashion.  (A
module that provided Linux's OABI syscall interface via SWI)

http://www.realworldtech.com/page.cfm?ArticleID=RWT110900000000&p=1

Real World Technologies - ARM's Race to Embedded World Domination
by Paul DeMone

On 14 Okt, 00:36, Rob Kendrick <n...@rjek.com> wrote:

It may be argued that these things are still driving the design, in
particular performance/Watt.

In other words, the "joy of the programmer" doesn't appear to have
been a design aim, and in fact, RISC processors have tended to be more
difficult to program in assembly than CISC processors, due to it
typically requiring more instructions to perform a task, compared to
the CISC version.

Fortunately, the ARM marries the easy to program part with
performance, but my point is that it appears they are still following
the original aims, even if it has lead to a drastically more complex
processor (especially due to all the specialised SIMD, etc.
instructions).

--
Steve Fryatt - Leeds, England

In a way, I guess you can say that simplicity was part of the original
aim, because they were (intentionally) set up in such a way that they
had to keep the design very simple...

Don't get me wrong: I like simplicity, as well. Just so you know where
I'm coming from, these are some of the things I in particular
appreciate about the ARM (which were even more unique at the time it
was released):

16 32-bit general-purpose registers
Three-register architecture
Conditional execution of every instruction
Optional updating of the PSR
Optional shift of one of the operands
32-bit instructions
Simple, yet complete instruction set

The extASM assembler (mentioned in an earlier message) auguments this,
by providing "auto-expansion", by increasing the range of operation of
each instruction, by automatically changing it, or substituting it
with several instructions, for example:

MOV R0,#&1234 -> MOV R0,#&34 : ORR R0,R0,#&1200
AND &FFFFFF -> BIC &FF000000
LDR R0,label_outside_range -> ADR R0, label_outside_range (auto-
expanded) : LDR R0,[R0]
etc.

This makes it possible to write assembly code with less concern for
the limitation of the instructions (although you should understand how
they are transformed, when needed, so that you don't inadvertantly
create inefficient code).

Now, some of the things in the above list don't quite hold, anymore,
namely:

Conditional execution of every instruction
Simple, yet complete instruction set

I'm no expert in microprocessor design, and maybe real-life use have a
need for 30 or so different variations of the multiply instruction, as
well as the plethora of other instructions in ARMv7, some of them
appearing to be very specialised.

I, too, prefer general facilities, compared to specialised features
and instructions (which is why I liked ARM so much when it came, and
why I disliked, and still do, the x86, with its abundance of special
cases and baggage from the past).

However, I also realise that for the ARM to be able to compete in its
market (or any market), it may need to acquire specialised or esoteric
features. I don't care much about Thumb, either (and it won't be
implemented in extASM), but I understand that in some segments of
their market, code desity is important (even if it reduces
performance), and it is, after all, their market.

I would have preferred that ARM focused more on performance, and less
on low power use, competing against processors like x86, rather than
aiming for the mobile market, which could have avoided quite a bit of
these things (such as Thumb). However, I also realise that they may
not have had much chance against giants like Intel in this market, and
it appears that going for the niche market of mobile and embedded
devices have been a winning move.

Since you're clearly not happy about the way the ARM processor has
evolved, let me ask you this: What would you have preferred that ARM
(the company) did differently, and would it have made business sense
(enabling them to survive and grow their business)?

Just to be clear: I like simplicity, elegance, and generality of
design just as much as you. It's just that the reality of the market
you're in will shape the design, and sometimes it may be difficult to
keep some of these things as a design evolves.

The Archimedes architecture has fast interrupts (FIQs), and so saves the
cost of a DMA controller.  When the floppy controller produces a byte, the
processor gets a FIQ, stops what it is doing, grabs the byte, stores it in
memory then gets back to work.  Due to the separate overlay registers
R8-R15, there's minimal overhead in switching to the FIQ routine.  Econet
works on the same principle.

This means you can throw away the extra hardware demands, but it doesn't
scale.  If the floppy controller is producing 10Kbyte/s, you can cope with
10K interrupts/sec.  If it's producing 10Mbytes/s, you can't.  The extra
hardware really does win in the end because it decouples the CPU from the
I/O.

But the idea of FIQs is a good one, especially in the embedded sphere. And
it does allow you to do things you couldn't previously do, with (AFAICS)
minimal knock-on effects for other things.

I'd want it 32 bit friendly and I'd want it to work pretty much as it
does now. I'd probably just convert the event handlers to asm and
leave the rest of the stuff in BASIC. After all it's the animation and
re-draw stuff that needs to be quick. This would have two advantages
over doing it in C. I would be able to work on the existing code-base
rather than re-coding from scratch. I wouldn't have to learn the ins
and outs of how BASIC stores files written in PRINT# format.

I think you will find learning assembly code rewarding... I agree with
you about x86 vs ARM: I would never want to write x86 assembly code...
Then I'd rather go for a higher-level language. However, I've found
writing ARM assembly quite fun and rewarding, and as mentioned in an
earlier post, I'm currently updating the extASM ARM assembler, which
is itself written in assembly (about 25,000 lines of it), to the
latest ARM models (ARMv7).

extASM is a free-standing assembler, but if it turns out to be a
practical possibility, now that we have RISC OS Open, it might also be
used as the basis for an updated BASIC assembler...

There are a _lot_ of new instructions in ARMv7, compared to ARMv3/
ARMv4 (the ones currently in use in computers like RiscPC), including
a powerful floating point instruction set (something that has been
sorely lacking for years), long multiply instructions, and SIMD
instructions, and these are currently unavailable in the BASIC
assembler.

Also, to take advantage of them, you need to run RISC OS on hardware
with the latest ARM models, such as the BeagleBoard, or Touch Book (if
we get RISC OS ported to the latter).

Regards,

Terje

Jochen

--

Anyway, enough of strained analogies.

However, I eventually abandoned ASM in favour of Acorn's ObjAsm
because ASM is far less powerful than the assembler built into BBC
BASIC. I needed an assembler with all the features of the BASIC
assembler but which could generate AOF output for linking with new
code that I had written in C for Star Fighter 3000. As a result, the
source code for Star Fighter 3000 is currently a mixture of C, ASM and
ObjAsm assembly language!

The trouble was that ASM doesn't support loops and its support for
conditional assembly is severely limited in that sections of code can
only be included or excluded depending on whether or not a 'flag' has
been defined. In contrast, ObjAsm allows arithmetic, boolean and
string variables with either local or global scope, and can evaluate
complex expressions as the condition for its WHILE and IF directives.

As an example of the kind of thing that would be impossible using ASM,
here is a snippet of the texture mapping code for SF3000:

  GBLA text_compile
text_compile SETA firstmapper
  WHILE text_compile <= 4
    ROUT
    [ text_compile = 1
text_res SETA 2
bonus_texture SETL {FALSE}
    |
      [ text_compile = 2
text_res SETA 1
bonus_texture SETL {FALSE}
      |
        [ text_compile = 3
text_res SETA 0
bonus_texture SETL {FALSE}
        |
          [ text_compile = 4
text_res SETA -1
bonus_texture SETL {FALSE}
          ]
        ]
      ]
    ]

Richard Murray provides an appraisal of various assemblers for RISC OS
machines here: http://www.heyrick.co.uk/assembler/apcsasm.html
I certainly disagree with his opinion that "ASM leaves objasm
standing", although no doubt someone will be along soon to say that I
have unfairly impugned ASM.

I made the transition from programming BASIC to programming in C
almost exactly ten years ago. At the time I was disappointed with the
poor performance of early programs that I wrote in C (which no doubt
used floating point arithmetic liberally). In retrospect I suppose I
was still in thrall to the proud claims on the packaging of Archimedes
games that they were '100% hand-optimised machine code' (as if that
were a good thing!). However, I have since realised that using
efficient and appropriate algorithms is far more important than the
choice of language used to implement them.

If optimisation is required then an experienced C programmer can use
simple tricks like using automatic variables to avoid dereferencing a
pointer multiple times, whilst keeping in mind the limited number of
variable registers available within each function. (It is no faster to
load an automatic variable's value from the stack than it would be to
access a structure member by dereferencing a pointer, and the ARM has
already wasted time by copying that member's value to the stack!)

I often optimise my C programs after examining the ARM code produced
by the compiler, but nowadays I would almost never abandon the
abstraction and portability of C in favour of assembly language. It's
nice to be able to compile the same source code for other platforms,
even if the results are sub-optimal! :-)

My early attempts at writing C were stunted by the fact that I was
translating directly from BASIC (sometimes mentally, sometimes using a
program that I had written to do the conversion automatically). There
are superficial similarities because they are both imperative
languages, but C is so much more powerful than BASIC that I urge you
to discard your preconceptions and buy a decent textbook on C
programming. I like 'The Practice of Programming' by Kernighan and
Pike.

For example, the lack of function pointers in BASIC makes it almost
impossible to write reusable code that doesn't suffer from hopeless
interdependencies between modules. Other features of C which initially
passed me by were the ternary operator ?: (best used in moderation),
the fact that the three expressions following a 'for' statement can be
*anything* (whereas BASIC's FOR keyword can only be used to iterate
through a linear numeric series), and the nicer alternative to GOTO
provided by the 'break' and 'continue' statements.

Great to hear from one of the authors (or maybe the author) of
Starfighter 3000, my favourite Archimedes game... :)

Granted, it's understandable, as hardly anyone knows about it, not at
least because it has no (proper) homepage, and it hasn't been updated
for over a decade, until recently.

Still, even at that time, it supported essentially a superset of the
BASIC assembler functionality (including loops, conditional assembly,
arbitrarily complex int/float/string expressions, etc.).

Besides, as mentioned in other posts, it's useful to know what is
happening "at the bottom", even when using a high-level language. It
could help to avoid or pinpoint performance problems, for example.

It can also help you understand how high-level programming languages
work. For example, I had no problem understanding the "pointer"
feature in C, after having done some assembly programming earlier:
It's simply the address of a variable (or some other entity)... :)

I've heard that some have had great conceptual problems with
understanding pointers, but that didn't happen to me...

Still, there are some areas where I've found assembly programming to
fit quite nicely, and an assembler is one of them. :) Assembly is good
at "bit fiddling", and there's a lot of that in an assembler/
disassembler.

Still, if I were to write an assembler, today, I'd likely done it in C+
+, using the Spirit parser framework, or something like that, which
would enable one to work at a higher level of abstraction, and leave
more of the "boilerplate" to the compiler/library.

Regards,

For example:
1) In each function a maximum of 6 fast temporary storage locations
are available to hold automatic variables of type 'char', 'int',
'short int', 'long int' or 'void *'.
2) If too many automatic variables of the above types are declared
then some will be held in slower temporary storage.
4) Using the '&' operator to get a pointer to an automatic variable
forces it to be held in slower storage.
5) Automatic structures are always held in slower storage locations.
6) Calling a function or assigning to an l-value through a pointer
invalidates any values previously accessed through pointers that might
otherwise have been cached in fast temporary storage locations.
...etc

It's true that the old 16-bit x86 was horrible to program, because of
the asymmetrical nature of its instruction set (certain instructions
only being able to use certain registers).  Modern 32-bit IA-32 code
is much nicer, because (with few exceptions) all the registers are
equivalent.

I'm not qualified to comment on RISC OS, but on MS Windows using a
hybrid of BBC BASIC and assembler is a very powerful technique.  All
my 'large' applications are written that way.  In the case of games
programming, David Williams' site illustrates the sort of thing the
technique can achieve (you'll need a Windows PC to run the programs,
but there are YouTube videos of some of them):

 http://www.bb4w-games.com/

Hi Richard.

Also, I understand what you mean about the conditional executed
instructions. They take some getting used to, but once you've wrapped
your head around them, they may lead to very succinct code (and
eliminating many jumps). For example:

IF (A=1 OR B=2) AND C=3 AND D=4 THEN...

CMP   R0,#1
CMPNE R1,#2
CMPEQ R2,#3
CMPEQ R3,#4
BEQ   ...

By the way, your BBC for Windows is very nice. :) (I've got a licensed
copy of it)

Regards,

If you know in advance something about the statistics (for example you
know that D is hardly ever 4) then doing that test first and bailing
out if it fails may be more efficient than testing all four registers
every time.

Richard.
http://www.rtrussell.co.uk/
To reply by email change 'news' to my forename.