Date   : Thu, 18 Nov 2010 03:22:41 +0100
From   : rick@... (Rick Murray)
Subject: Hints'n'Tips: Assembling non-ARM code on ARM BASIC

On 17/11/2010 17:11, J.G.Harston wrote:

> There isn't an OSCLI call to read what the machine type is

Mmmm... "*FX 0,1" but how do you read the result in a multi-system 
friendly way?


> there was, the *machine* type is not what I need to know, it's the
> *language* processor that I need to know.

Fair enough.


> But, I suppose too many people have been brought up with Microsoft
> products where hours spent going click, click, ok, click, click, ok
> click, click, ok, is the only way of doing things.

Oooh, mioaw!


Actually, I was brought up with Beebs and then Archimedes, and moved to 
the realm of Microsoft when RISC OS started showing too many limitations 
for being able to do the day to day stuff I want.

One of my thoughts on the matter is that, by and large, a lot of source 
can be shared multisystem, but really it is better to write 
system-specific code with the generic back-end being shared. This may 
sound like it involves more work, and it does, but it also permits you 
to maximise the potential environment in which you will be operating in. 
But, then, wait... what source management tools do you use? Oh, I see... 
It's an interpreted language where the code assembles itself every 
single time. Right. [me being bitchy in return ;-)]


Seriously, though. I do wonder if it isn't better to have parallel 
projects for RISC OS BASIC offers a lot of constructs that are extremely 
useful - complicated IFs, CASE structures, WHILEs, the ability to update 
calling parameters [ DEFPROCblah(RETURN A%) ], and to top it all off, 
pretty much the world is your oyster with SYS.....
Would it not be better to code for RISC OS versions to make best use of 
the enhanced facilities available?


Best wishes,

Rick.

-- 
Rick Murray, eeePC901 & ADSL WiFI'd into it, all ETLAs!
BBC B: DNFS, 2 x 5.25" floppies, EPROM prog, Acorn TTX
E01S FileStore, A3000/A5000/RiscPC/various PCs/blahblah...