Cross-Platform ARM App?

Hi there,

I’ve just developed my first Android app (using Eclipse on the Mac) and found it a bit unwieldy in places. I know Android uses ARM processors, so with my interest in RISC OS development it posed a question for me :

Is it possible to develop an App in BBCBasic, RISCOS C/C++, or Assembly that would work on any ARM device – e.g. Android Phone, Raspberry Pi and – dare I say it – Windows RT etc, regardless of OS ?

I suspect that Android won’t have the same high-level calls to the OS as in RISC OS (so BBCBASIC and C are probably out), but surely the low-level – i.e. Assembly commands would be the same – regardless of platform – or would they? i.e could an ARM assembled “app” be produced on a Ras Pi under RISC OS, and be copied (or recompiled) to run on an Android phone?

Really interested in knowing if this is possible.

Cheers
Andy

Yes and No.

if you write in pure assembler (does Android cope well with that instead of Dalvik code?), you can do it under RISC OS with the caveat that you will need to use libraries specific to Android, and be aware that SWI xxxxx does one thing under RISC OS and likely something else under Android (IIRC the SWI number is passed in a register, not an instruction).

As for C, it is more complex. Not only do you need to link with Android libraries, you need to ensure the calling conventions match up (which register is stack pointer, frame, which can be trashed, are all registers passed on stack or is a0-a3 then stack, etc etc etc).

Is it possible to develop an App in BBCBasic, RISCOS C/C++, or Assembly that would work on any ARM device – e.g. Android Phone, Raspberry Pi and – dare I say it – Windows RT etc, regardless of OS ?

Simple answer: Yes, as long as you don’t need any input or output of any kind! ;-)

Sadly as soon as you do (and let’s face it, you do) then you would require an abstraction that works across all your target platforms. This is a problem that is as old as computing, and has led to solutions such as POSIX, which is Unix/Linux, basically.

Having written an Android app in addition to RISC OS code you’ll be aware of the very different high-level idioms. Different OSes just have very different ways of doing things, and abstracting them all usually ends up with a very limited subset… and not a very attractive one. Hence all those hand-me-down command line utilities RISC OS inherits from Unux.

In any case, targeting a single processor flavour (as RISC OS does) is so last century as Linux, Android and even Windows 8 demonstrate. And the power of modern hardware means there’s now almost no excuse for writing code at such a low level. My advice these days is to learn Javascript.

No, really. Learn Javascript. Properly learn it. Don’t just look at some and think it looks like C/C++/C#/Java and you understand it already. You don’t. Don’t think it’s only any use for animating buttons on websites. It isn’t. My considered professional opinion is that all programmers should learn Javascript. If only to avoid looking like a fool.

Anyway… there are environments such as Qt (“cute”) which target multiple platforms so you can write code once and deploy it on Macs, PCs, iOS and Android. Sadly there’s no RISC OS version!

The other thing that has crossed my mind is that Android’s kernel is linux… but it doesn’t have to be. Android-on-RISC-OS is possible (though probably not achievable) and would be pretty attractive. Imagine being able to run Android apps alongside Wimp programs. Windows 8 done properly!

Thanks for this clarification. I suspected it wouldn’t be easy!

Nemo: You say “learn Javascript”. I already have! I do a lot of websites (PHP / ASP (yuk)) and have had to learn Javascript to do some of the client-side things, and have become proficient in it. I’ve heard of dynamic-Javascript for reading databases etc, and have tinkered with QT and JQueryMobile (as well as MonoDevelop and Java and others). These environments are all well and good for Mac/PC/Linux environments, but I’d love to be able to cater for RISC OS as well; but of course web-based applications should still work on RISC OS, shouldn’t they? NetSurf is the default browser nowadays?

My Android app makes use of a barcode reader (ZXing) which was fairly easy to incorporate into my app, but I believe that would be non-trivial to do with a one-size-fits-all package like QT or JQueryMobile.

What are people’s feelings about Java apps? Could I create a standalone app (i.e. not necessarily with web access) that would work on RISC OS too? I’ve heard of issues with “security” flaws with Java – so that’s made me reluctant to use it.

web-based applications should still work on RISC OS, shouldn’t they?

I agree with the “should”. I’m not confident about “do”.

What are people’s feelings about Java apps?

1. Irrelevant to RISC OS
2. Irrelevant

My Android app makes use of a barcode reader (ZXing) which was fairly easy to incorporate into my app

Indeed. Android-on-RISC-OS would be awfully attractive for exactly that reason!

Simple answer: Yes, as long as you don’t need any input or output of any kind! ;-)

Yeah, people go on and on about how “portable” C is, but the fact is the portable part is extremely restricted (you can open files, print stuff, get simple input) but you can’t list files in a directory and you are off-limits with anything smarter than a basic unformatted line-by-line output (no VT codes, no ANSI colours, definitely no GUI). As soon as you need any of that, the program is no longer portable.

Then there’s another lurking “gotcha”. I write some image fiddling code. It used “int this;” and “int that;”. Worked a treat under RISC OS. Failed horribly under DOS, for a DOS int is half the size of a RISC OS int. Needed to make ‘em all “long” for it to work [and then there’s that memory model bull that used to plague the DOS compiler days, thankfully _far and _near were rejected from inclusion into the C standard…).

IMHO, “portability” is a myth unless you are coding for something that isn’t real that can be implemented on various different platforms. This being a basic description of Java. And even then…

problem that is as old as computing, and has led to solutions such as POSIX, which is Unix/Linux, basically.

And is very heavily dependent upon aspects of how Unix works (the ‘/’ root directory; threading and spawning child processes; etc).

Hence all those hand-me-down command line utilities RISC OS inherits from Unux.

Probably simpler than trying to port an x-windows application…

In any case, targeting a single processor flavour (as RISC OS does) is so last century as Linux, Android and even Windows 8 demonstrate.

Different methodology.

Android doesn’t count, it is pretty much (heavily) bastardised Linux.

Linux itself seems to be written with the design principle of the least amount of assembler necessary, and that’s pretty much glue to do the low-level fiddling that you can’t manage in C… though as Canonical showed when they dropped ARMv6 in favour of ARMv7 optimisations, it doesn’t necessarily hold true that something written high level will support all sorts of processors. For sure it is magnitudes simpler to port (RISC OS on x86? ain’t never happ’nin) but after all of this, somebody somewhere needs to support your processor.

And the power of modern hardware means there’s now almost no excuse for writing code at such a low level.

RISC OS normal not-specially-optimised-boot on a Pi is sixteen seconds. You don’t need to take my word for it, I videoed it: http://www.youtube.com/watch?v=idN0Cph1hh8
It seems to me that Linux typically takes rather longer to get going unless you start playing with how it boots (like buildroot, precached system-specific info, etc).

No, really. Learn Javascript. Properly learn it.

No thank you. There are too many versions with too many stupid little quirks. Wanna see? Take the UserAgent string for a Webkit browser and paste it into the UserAgent for Firefox and see how many sites break – Facebook, dead (yay!), Flickr dead, GoogleMaps fail.
Here you go, it’s this:

Mozilla/5.0 (Windows NT 6.2) AppleWebKit/536.6 (KHTML, like Gecko) Chrome/20.0.1090.0 Safari/536.6

Why is this happening? The server is reading the UA to determine which flavour of JavaScript actually works on your browser, and sending it appropriately. As you are lying about your browser, you get the wrong scripts, and it all stops working.

Don’t just look at some and think it looks like C/C++/C#/Java and you understand it already.

That’s about my level of understanding. Sufficient to drop some stuff into my site, and that’s that.

Don’t think it’s only any use for animating buttons on websites. It isn’t.

Oh, it can do a lot more (GoogleMaps is some amazing code), but in a fully platform independent manner it’s pretty much only useful for animating buttons on websites…

This doesn’t mean I “don’t know” JavaScript, it means that I never bothered with the nitty-gritty cool Ajaxy-Whoo-Hoo details as I don’t fancy the idea of arbitrarily restricting who can make use of my site based upon their choice of browser (and since I’m kind of lazy at times, I baulk at doing the same thing multiple times because people can’t agree on stuff).

My considered professional opinion is that all programmers should learn Javascript.

Is this like “you are supposed to learn Pascal”?

I get it, Pascal drags you kicking and screaming from BASIC to the idea of typed variables, reusable code libraries, public/private functions, etc etc. However having learned Pascal and swiped a copy of TurboPascal from the college computer (latterly, it was a freebie on Borland’s site for a nostalgia kick), I don’t think I really ever did anything useful with it. It was just a “oh yeah, I remember something like this” while teaching myself C.

It should have been: Stuff Pascal, learn C.
Likewise: Stuff JavaScript, learn <insert something you plan to use a lot – PHP, Ruby, Java, etc>

If only to avoid looking like a fool.

Never troubled me in the past… ;-)

Anyway… there are environments such as Qt (“cute”) which target multiple platforms so you can write code once and deploy it on Macs, PCs, iOS and Android. Sadly there’s no RISC OS version!

I wonder if Qt could be ported to RISC OS in some manner?

I don’t know about how well Windows supports the Qt runtime (as in, is it 100% complete?), however I feel the need to point out… latter-day MacOS, PCs (with Unixen), iOS, Android – they’re all basically variations of the same core system. The only difference would be PCs with Windows, but you didn’t specify.

The other thing that has crossed my mind is that Android’s kernel is linux… but it doesn’t have to be. Android-on-RISC-OS is possible (though probably not achievable) and would be pretty attractive. Imagine being able to run Android apps alongside Wimp programs. Windows 8 done properly!

No, Android’s kernel probably does have to be Linux. If you were to change the kernel, you’d be changing the heart of the OS and the result wouldn’t be Android…

The apps are (typically) a higher level using the Dalvik (Java) runtime.
RIM suggests their Playbook OS is going to (soon?) support Android apps through a sandboxed “app player”. It may be possible to consider something akin to that for RISC OS (although one doesn’t usually wake up one morning and think “I’ll write an Android app runtime today!”).

What are people’s feelings about Java apps?

I got sick of reading ElReg’s reports of The Next Big Java Problem (here’s an example) alongside Firefox saying that one of my add-ons may pose a risk so it has been disabled…
…so now Java has been disabled on my system (the JVM is still there for running applets from the command line; but browser support has now gone). Can’t say I’ve noticed I’m missing anything I need.

This is talking about a Windows PC.
For RISC OS – isn’t our JVM incomplete and something like 15 years old? Probably a lost cause…

Android doesn’t count, it is pretty much (heavily) bastardised Linux.

1. My point is that apps are compiled to a virtual machine, not a particular processor architecture. NDK aside, same app runs on different processors
2. The programmer’s model certainly isn’t “linux”

It seems to me that Linux typically takes rather longer to get going

Post hoc ergo propter hoc. Linux isn’t slower to boot because it is written in C.

No thank you. There are too many versions with too many stupid little quirks. Wanna see? Take the UserAgent string for a Webkit browser

No. You’ve just been lamenting the differences between compilers harming C’s platform independence. Now you cite historical differences in browser implementations as being JavaScript’s fault. They aren’t.

In any case, the days of unilateral proliferation are over – all browser developers are working towards the same standard, and that will be called “Harmony” as it happens.

I’m quite serious about advising programmers to learn JavaScript, especially people such as yourself who are prejudiced against the language for spurious reasons. You should learn the language, you will learn some really cool stuff (about JS, and about programming).

Douglas Crockford’s “Javascript: The Good Parts” should be on your shelf already. If not, put it on your Christmas list.

Don’t just look at some and think it looks like C/C++/C#/Java and you understand it already.

That’s about my level of understanding. Sufficient to drop some stuff into my site, and that’s that.

<facepalm> What did I just say? This is precisely the problem. I would put money on you not actually understanding the language you’ve used. How can you judge it if you don’t understand it?

I wonder if Qt could be ported to RISC OS in some manner?

It’s open source, I don’t see why not.

I don’t know about how well Windows supports the Qt runtime (as in, is it 100% complete?)

Yes.

No, Android’s kernel probably does have to be Linux.

Oh bollocks. It absolutely doesn’t. How do you think the Windows Android SDK works?! Also, BlueStacks: http://bluestacks.com/app-player.html

Actually Rik, bollocks to your “Linux boots slowly” comment too.

Linux booting in a virtual PC implemented in Javascript running in a virtual machine in your browser: http://bellard.org/jslinux – boots in 6.7s on my ancient XP machine.

As I say, writing code at the processor level seems somewhat outdated for the majority of usage cases.

Actually Rik, bollocks to your “Linux boots slowly” comment too.

It would depend on the distro and the tat stuffed in the boot I suppose.

My point is that apps are compiled to a virtual machine, not a particular processor architecture.

That’s not “Android”, that’s an Android “app”, which – akin to Java to which it is related – will function on any suitable runtime. As I said, RIM’s PlayBook (as in “Blackberry”) is planning a runtime for Android apps.

The programmer’s model certainly isn’t “linux”

Are you talking here about Android itself or the “apps”?

You said in the previous message:

In any case, targeting a single processor flavour (as RISC OS does) is so last century as Linux, Android and even Windows 8 demonstrate.

So forgive me if I (incorrectly?) assumed you were talking about the operating system itself – which when connected via adb looks and feels a hell of a lot like Linux, don’tcha think?…

Linux isn’t slower to boot because it is written in C.

I grew up in a time when people used to write stuff in C and use hand-optimised assembler for bits that needed speed. This isn’t to say that compiled C is inherently bad, however there are some tricks even the compilers don’t know about that can be employed to get the maximum results from a slow processor.
So to Linux, where there is very little ‘glue’ code with most of it (even to the level of task swapping and such) exists in high level code. I believe two things. I believe that Linux is slower due to this, and I believe on modern systems you won’t be able to tell the difference.

Perhaps the boot lethargy is just bad practice? It is possible to strip a ~1 minute boot time down to ~15 seconds by employing a variety of tricks. Maybe some of them are things Linux should have done in the first place?
People who play with RISC OS on the Pi are frequently blown away with how nippy and responsive it is. Maybe the fault with Linux is not that it is written in C, but more that it is written in an HLL encourages bloat which in turn leads to lethargy?

I can give you a class example by pointing to my PVR which runs a stripped version of Debian & Qt4 on a 200MHz ARM926 (TMS320DM320). The people that built the thing made two versions of the firmware. The first was Debian and NanoX. It was small, compact, kinda plain but did its job. Then came the second version that sings, dances, and is Debian/Qt4. The CF slot on the front now needs to have a CF with ext filesystem always mounted because the Qt libraries blew a hole in the 16MiB flash. The OS boots from Flash, the Qt stuff in on CF. I find it to be horrific that a nice display and runtime support for what it, primarily, a video recorder consumes over 20MiB.
By constrast, the crappy looking (pixel text, etc) custom firmware in my older PVR is around 4 1/2 MiB and most of that is the codec stuff. The older firmware, I should point out, starts up in ~35 seconds as opposed to the ~3 minutes of the fancy PVR. Same chipset. Maybe the “written in C” is just a red herring and “written everything but the kitchen sink into the kernel” is the real case here?

No. You’ve just been lamenting the differences between compilers harming C’s platform independence. Now you cite historical differences in browser implementations as being JavaScript’s fault. They aren’t.

Historical ? I gave you a test to do if you felt so inclined to demonstrate that JavaScript is not cohesive even today. I can forgive the past – all kinds of crazy nonsense went down in The Browser Wars. But we’re still not there yet.

As for talking about C’s platform independence, I was actually pointing out that it is a myth. Sure, you can cross-compile all sorts of simple trivial little things; but the fun and joy of porting is that as soon as you get to anything useful, this supposed “platform independence” evaporates like cheap wine spilt on a hot stove…
…as I said, the generic C libraries don’t even include a way to list the contents of a directory. Instead you get such useful things as rewind() (what’s wrong with fseek(fp, 0L, SEEK_SET); ?), plus such loveliness as ungetc() that just strikes me as a bodge that got itself enshrined in the language.

While I’m kicking rewind(), here is its formal description from the DDE’s “Libraries.clib.h.stdio” file:

* sets the file position indicator for the stream pointed to by stream to
* the beginning of the file. It is equivalent to
*          (void)fseek(stream, 0L, SEEK_SET)
* except that the error indicator for the stream is also cleared.
* Returns: no value.

So not only is it the same as the fseek() that I use, but it returns no value and clears the error marker. Consequently, there is no way to determine that rewind() actually worked without subsequently checking. In short, it’s a pointless bit of cruft in the language. And we have this instead of things that might have aided this notion of “platform independence”.

all browser developers are working towards the same standard, and that will be called “Harmony” as it happens.

I’ll believe that when I see it.
One player still only sort-of gets the idea of following standards, and I bet they are only doing that because the other major players are implementing a broadly consistent set of standards. Must suck to no longer be #1 and not compliant with everybody else.
One other player had the smart idea of replacing interpreted code and such with… native code ! Are we going back in time?
Then there’s the use of “-webkit” prefixes for features that weren’t official when WebKit did them, but are official now, only people still use the -webkit version. More in the left column of WaSP .

As for Harmony – do you mean this ?

This is precisely the problem. I would put money on you not actually understanding the language you’ve used.

That’s pretty much a given, don’tcha think? It cut’n’pasted enough to do what I needed to do. Call it Cargo Cult Programming if you will.

Though, I must say I’m quite impressed by the x86 emulator.

Oh bollocks. It absolutely doesn’t. How do you think the Windows Android SDK works?!

SDK? As in Software Development Kit ? Funny, there was me thinking it was a set of programs for the host OS and an emulator for testing the compiled software in the absence of an actual phone/tablet to push the code to.

SDK != OS

Actually Rik, bollocks to your “Linux boots slowly” comment too.

If you wish to lower the tone of the conversation with words like “bollocks”, please at least be rude to the right person. I’m not Rik, I’m Rick.
Normally I wouldn’t be so pedantic, however there is somebody called “Rik” here (who has yet to post in this thread).

Linux booting in a virtual PC implemented in Javascript running in a virtual machine in your browser: http://bellard.org/jslinux – boots in 6.7s on my ancient XP machine.

That emulator is actually pretty cool. However, I will point out that your 6.7s statistic is meaningless as you don’t define what “ancient XP machine” is.

Try this. eeePC901 (1.6GHz Atom), on Firefox 3.6.27 with numerous active tabs but no other applications running, connected to the outside world via Wifi .n (13Mbps) and an ADSL link that can run up to around 1.8Mbps.

Booted in 107.934 s
Welcome to JS/Linux

It takes me longer than your 6.7s to get to “Starting Linux”; but then it does need to also pull in a 1.73MiB kernel and a 15KiB bootstrap. No idea about how much is loaded of the drive image…

I suspect the lagginess here is the JS engine in this version of Firefox, rather than the system it is running on.

I understand and agree that there are numerous benefits of writing stuff in high level languages. I also understand (and would agree) that there are times when using assembly is beneficial. I think the time for implementing new operating systems from the ground up in assembler have long gone, and in this respect RISC OS remains a pleasing oddity, a nod to a culture of people who knew how to program efficiently. To this end, it is perhaps no mistake that RISC OS seems more closely aligned with embedded systems than big fancy behemoths. In fact, I would be inclined to suggest that RISC OS could – if it attracts a good development atmosphere – be a rather unique bridge between the small embedded devices (frequently programmed in assembler unless it has some sort of runtime embedded for a C-like or BASIC-like method of programming) and big behemoths probably running a Linux variant. With RISC OS you can have services, features, filesystems, and pretty windows. But you can also have speed, hijack interrupt handling, replace or customise bits or swathes of the OS, as necessary.

You mustn’t forget, we’re looking at an OS with a heritage back to the mid ’80s. Back then, huge chunks of assembler was not unheard of (SIBO, AmigaOS, MS-DOS…). Original Unix itself was first written in assembler, then rewritten in C.

That an operating system from a long-gone ‘80s Micro manufacturer written in absurb piles of assembler is running, today, on the RaspberryPi and similar, well, just goes to show you that maybe this assertion isn’t quite as crazy as it might seem. The impossible has happened. It’s sitting on the table in front of me. I couldn’t have dreamed of a gigahertz ARM sporting a half-gigabyte pile of memory. Even in the RiscPC days, such things were unimaginable. Now I have it, I’m not entirely sure what to do with it. I mean, I could go “wheeeee!” and load up five thousand, one hundred, and eighty copies of !Edit – but that seems like a bit of a waste, don’t you think? RISC OS software has always been small, tight, and not megabytes of bloat, so it stands to reason that around 20MiB of the memory gets exercised regularly, while the remaining pile twiddles its thumbs, but not in a cute Rikka-Takanashi-in-the-opening-credits kind of way…

Looks like each way has its benefits, and its problems.

Just two questions…

1. Is there javascript support on RISC OS?
2. Is there a current java sdk/jdk avaliable in RISC OS?

If not, how would either of these be portable to RISC OS?

Python is OK, and fairly portable.
Not sure about android et al

Just look at firefox for a reason not to use javascript.
Optimisation now means a complete rewrite from the ground up, that’s not what I was brought up it to mean, how many times are we on?
Firefox was supposed to be a lean browser in the 0.1 days , not so much now….

FYI Windows NT supported multiple platforms, IMHO supporting multiple platforms on a desktop OS is an insanely bad idea.
Windows as a desktop is realistically only supported on intel.
Mac OS is only now supported on intel
The most stable and reliable operating systems generally are designed for one platform

My point is that apps are compiled to a virtual machine, not a particular processor architecture.

That’s not “Android”, that’s an Android “app”

Indeed, but considering the performance of such machines, the distinction between the two diminishes – despite Moore’s Law our hearing doesn’t get any finer, so when it comes to sound generation what used to be written in tight MC can now be generated in a high-level scripting language.

there are some tricks even the compilers don’t know about that can be employed to get the maximum results from a slow processor.
So to Linux, where there is very little ‘glue’ code with most of it (even to the level of task swapping and such)

I fairly recently hand-optimised an ARM blitting routine to improve throughput by 33% over the compiler-generated code (and this is high resolution stuff). Difference in performance for the whole system? Not measurable. As soon as you involve IO or process swaps (which are orders of magnitude slower than your “glue” code) such ‘tricks’ are meaningless, unless the system is utterly trivial.

Maybe the fault with Linux is not that it is written in C, but more that it is written in an HLL encourages bloat which in turn leads to lethargy?

Well, it could be argued that part of Linux’s problem is that it’s written by 20,000 people with different ideas of how things should work, so it’s a camel. Comparing RO boot time with Linux boot time is comparing apples with oranges (or crab apples and Ugli fruit, more accurately).

I find it to be horrific that a nice display and runtime support for what it, primarily, a video recorder consumes over 20MiB.

Quite so. Putting a server class OS in an appliance is an absurd but sadly economically-viable result of Moore’s Law… as is the observation that the hardware chosen to run the OS will be not quite powerful enough.

I gave you a test to do if you felt so inclined to demonstrate that JavaScript is not cohesive even today.

I wonder how many of your tests concern the language, and how many the various browser’s implementation of the DOM. I imagine more of the latter than the former.

I’ll believe that when I see it

http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts

at least be rude to the right person

Sorry Rick, that was a typo, and my colloquial phrases are jocular not desultory.

However, I will point out that your 6.7s statistic is meaningless as you don’t define what “ancient XP machine” is.

OK, same machine booting RISC OS 4 under VirtualRPC: 35s (though that’s to the desktop)

a nod to a culture of people who knew how to program efficiently

It’s at this point we have to quibble about what “efficient” means. In terms of shaving 33% off a loop, fine, aren’t we clever, but that also leads to monstrosities such as using a ‘non-standard shift’ in a comparison to preserve the carry and results in unmaintainable code. Plus, spending three times as long to write a loop that goes 33% faster once a fortnight is nobody’s definition of ‘efficient’.

That RISC OS still has physical hardware to run on is a lucky coincidence. Writing a hand-tuned ARM version of a routine that also exists in a high-level language is fine. Writing stuff ONLY for one processor is madness (in terms of longevity).

With RISC OS you can have services, features, filesystems, and pretty windows. But you can also have speed, hijack interrupt handling, replace or customise bits or swathes of the OS, as necessary.

In the real world, if Linux is too big, you probably want QNX or ThreadX.

1. Is there javascript support on RISC OS?

No. This is a bad thing.

2. Is there a current java sdk/jdk avaliable in RISC OS?

No. This is a good thing.

If not, how would either of these be portable to RISC OS?

A minimal JavaScript interpreter is about 100KB. A JIT compiling version can be much bigger (Google’s V8 is over 2MB).

Python is OK, and fairly portable.

Indeed, Python is great. The problem I see with python, ruby etc is that they aren’t just languages (and in fact aren’t very useful as languages) – they are language/library hybrids, and the libraries are MASSIVE.

JavaScript doesn’t have a library, it has the internet.

Just look at firefox for a reason not to use javascript.

Just look at Chrome for a reason to use javascript. I don’t see what citing one browser has to do with discussing the merits of a programming language.

Windows as a desktop is realistically only supported on intel.

MS have a long relationship with Intel. ARM limitations of Windows 8 are political (and marketing) rather than implicit.

Mac OS is only now supported on intel

That is Apple’s choice, and yet iOS is only supported on ARM. Again, political, not technical.

The most stable and reliable operating systems generally are designed for one platform

You seem to have forgotten about linux, conveniently.

Mac OS is only now supported on intel
That is Apple’s choice, and yet iOS is only supported on ARM.

As you say, Apple’s choice and more to the point rumour has it that the situation may well change soon. Something to do with increasing processing power in the ARM range and reducing code development variants. Not that ARM fans should celebrate – Apple move wherever their interests lie with no tinge of processor loyalty, which in commercial terms it understandable.

our hearing doesn’t get any finer, so when it comes to sound generation what used to be written in tight MC can now be generated in a high-level scripting language.

I’m not convinced that a scripting language would be able to do it well [and by this, I mean the scripting language generating the sounds, not just calling a bunch of prebuilt machine code library functions that does all the hard work…]; but certainly a Java app can do the sort of stuff that before required careful assembler. An example I’d point to being MilkyTracker for Android. Looks like crap on my phone (prob. better on a tablet!), but it’s a pretty good attempt at replicating the FastTracker MOD player.

I fairly recently hand-optimised an ARM blitting routine to improve throughput by 33% over the compiler-generated code (and this is high resolution stuff). Difference in performance for the whole system? Not measurable.

That’s why I said that I believe that Linux being written in C will have an affect on system performance; and followed it up with but on today’s hardware, you won’t be able to tell.

As soon as you involve IO or process swaps (which are orders of magnitude slower than your “glue” code) such ‘tricks’ are meaningless, unless the system is utterly trivial.

Depends – if your blitter was for a game, all the data should have been loaded and I/O stuff like sound running under interrupt by the time your blit would get an exercise. Plus, no task swaps.

In a normal use case, swapping process can be sped up with things such as lazy swapping (although the impact of that can be felt elsewhere as any Windows user can tell you) and I/O would work a lot better if it could run async on interrupt. For instance, should the machine freeze while spinning up and reading the root directory of an unknown floppy? No, it shouldn’t. You’d burn several hundred million instruction cycles saying “yo, flop, you done yet?!”. So if this was async and non-blocking, you could let the filesystem get back to you when it has an answer.
For others reading this – optimising the code, even 33% faster ¹ – it is just a part of the whole. To make something fast and responsive, everything needs to play its part otherwise we’re just taking a Citröen C1 and dumping a Ferrari engine into it. Might work for Brabus, but in the real world that’s just silly.

¹ One could point out that if you can hand-optimise something by a third over the compiled code, imagine that scaled up the the entire Linux kernel!

Well, it could be argued that part of Linux’s problem is that it’s written by 20,000 people with different ideas of how things should work, so it’s a camel.

Mmm… Could explain the forks. To each their own religion.

Quite so. Putting a server class OS in an appliance is an absurd but sadly economically-viable result of Moore’s Law…

Moore’s Law, or more likely “it has been proven to work and it is free to use”. As absurd as stuffing a server class OS into an embedded device is, surely writing your own OS from scratch when something usable already exists is even more absurd?

as is the observation that the hardware chosen to run the OS will be not quite powerful enough.

Well, the claims in the datasheet that the device can manage recording and playback of D1 are a little hokey at best. It is my personal suspicion that the DM320 is capable of handling D1 (that’s full frame PAL or NTSC) video, but the moment you add an OS to tie it all together, the D1 abilities vanish ‘cos there just isn’t enough headroom.
Still, 640×480 in anamorphic isn’t bad, it is hard to tell apart from a DVD at higher bitrates, and at lower bitrates it is better than VHS tapes and YouTube, so… ;-)

[me] I’ll believe that when I see it
http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts

Hehe… I didn’t mean when I see the spec, I meant when I see working implementations that certain groups don’t try to screw up for their own protectionist aims.

OK, same machine booting RISC OS 4 under VirtualRPC: 35s (though that’s to the desktop)

Well, VRPC is mind-numbingly quick anyway. But hey, you just made my point. RISC OS is incredibly quick to get going, even when it’s running on a PC! <stir><stir><stir>
(^_^)

It’s at this point we have to quibble about what “efficient” means.

I would say making the best use of the available resources for the most streamlined result. Oh my God, that sounds like something you’d see on a Powerpoint. Gah!

In terms of shaving 33% off a loop, fine, aren’t we clever,

The irony is, when such optimisation isn’t being performed by necessity (like a full screen real-time flight sim on an 8MHz computer), it is often done “just because”. Most of my optimisations have little purpose other than “because I can” and “because I feel the overheads of meh are too much” (using a highly arbitrary yardstick).

I tend to like to write my own jump tables because I do it better than any compiler I’ve looked at the code of. The DDE compiler (Castle generation) wasn’t bad, but wasn’t there yet. It branched to a set of branches to the routines (so close to perfection…!). You don’t wanna know what TurboC++ (16 bit world) and OpenWatcom (32 bit world) did. I suspect x86 code is just grotty however which way you look at it.

but that also leads to monstrosities such as using a ‘non-standard shift’ in a comparison to preserve the carry

Hadn’t we all learned our lesson when all the cool 6502 NMOS side-effects failed when the CMOS version of the chip was released and turned ’em all into NOPs?

Looking at the “compiler uses unaligned load to load 16 bit value in two instructions”², I suspect we’re just doomed to repeat our mistakes.

² The galling thing is that an unaligned load needs a load followed by a mask or shift to rotate the data into the correct place.
How is this different from a regular load and then either AND masking or shifting to get the halfword we want? That would be legal, surely just as quick, and not going to fall over on newer processors!

Plus, spending three times as long to write a loop that goes 33% faster once a fortnight is nobody’s definition of ‘efficient’.

Your blit routine is only called once a fortnight?! Jeez, you probably could have just SpriteOp’d it!

Writing stuff ONLY for one processor is madness (in terms of longevity).

I suspect there’s more of that than might be immediately obvious – why is (true) Windows only available on x86 hardware? If it was all high level code and some glue, it wouldn’t be too hard to recompile it for ARM or MIPS or whatever, world domination by having Windows7 run on loads of stuff. Word, Excel, etc could come with binaries for various different types of machine (.EXE for x86, .arm for ARM, .mip for MIPS, etc).

Granted, a lot of this is political too; however with Windows 8 on ARM not being like Windows 8 on a PC; either the two versions of Windows are inherently different for technical reasons (like lots of x86 specific stuff) or Microsoft are shooting themselves in the foot.
This is where Linux comes in. Ubuntu is Ubuntu is Ubuntu. On a PC, on a Beagle, on an unknown box – it’s a cool brown round widget that looks like something Lain would have liked (or it’s that <spit> Unity thing). Either way, look and feel isn’t that much different between ’em.

Score one for the HLL OS.

On the other hand, as I said in my previous post, RISC OS was written in the day when it wasn’t unusual to wrote OSs in assembler. By doing so, plus the somewhat unique benefit of the OS being written by the guys that designed the processor, the system spent some time kicking the ass of all of the other so-called home micros. Well, Acorn was on top for a short while. Some never made it that far (hello Tangerine Computer Systems, I’m looking at you).
Anyway, RISC OS was written in ARM code. It still is. Hands up if you fancy rewriting it in C or somesuch…oh, and it would be expected to be binary compatible otherwise what’s the point?

In the real world, if Linux is too big, you probably want QNX or ThreadX.

You don’t think, with some revision and tidying up, that RISC OS would have a place in the embedded world too?

<rant>

So not only is it the same as the fseek() that I use, but it returns no value and clears the error marker. Consequently, there is no way to determine that rewind() actually worked without subsequently checking. In short, it’s a pointless bit of cruft in the language.

It’s been a while since I worked with C. Too long spent enjoying the quirks of PHP and VisualBasic.

So I’m writing a configuration file loader having read Justin Fletcher’s guide twice (read from Choices:blah and write to <Choices$Write>.blah – why do some people have such difficulty here?) and it keeps failing when running the verification test to make sure the file being loaded is correct.

Then I look up the description of fgets():

extern char *fgets(char * /*s*/, int /*n*/, FILE * /*stream*/);
   /*
    * reads at most one less than the number of characters specified by n from
    * the stream pointed to by stream into the array pointed to by s. No
    * additional characters are read after a new-line character (which is
    * retained) or after end-of-file. A null character is written immediately
    * after the last character read into the array.
    * Returns: s if successful. If end-of-file is encountered and no characters
    *          have been read into the array, the contents of the array remain
    *          unchanged and a null pointer is returned. If a read error occurs
    *          during the operation, the array contents are indeterminate and a
    *          null pointer is returned.
    */

Reads at most one less than the number of bytes specified? That does it. The original specification for the standard C library was written by a drunken monkey and ain’t nobody’s gonna convince me otherwise.

Gah. Stupid! Stupid! Stupid!
If I ask for n bytes, I want to see n bytes. No exceptions (save for NL/EOF).

</rant>

Presumably because you give n as the size of the char array, and reading a maximum of 1 less than this allows for the terminating null character?