Is this true?

As an ignoramus in these things, I would have expected a 32-bit RO5 to be a necessary prerequisite for 32-bit RiscOS applications.
I sort of guess that Omega's built-in OS may see RiscOS as just another app (with the RiscOS apps as separate threads or something), and is either already 32-bit or can be upgraded.
But even so, how can a 26-bit aware process handle all those calls from those 32-bit applications?

Or are Microdigital thinking of 32-bit apps under some other OS - theirs or Linux maybe?

What the omega does is allows such applications to execute on the faster XScale, progs (RISC OS included) that use
the 26 bit register run on the Strong Arm.
The differnce between 26 bit and 32 bit is _nothing_ like the difference between 16 bit and 32 bit in PC land.

32 bit apps will run on an ARM 2 chip, what is meant by 32 bit in RO
is that the Apps don't try to use a 26 bit register that is missing from the XScale.

What the omega does is allows such applications to execute on the faster XScale, progs (RISC OS included) that use
the 26 bit register run on the Strong Arm.
The differnce between 26 bit and 32 bit is _nothing_ like the difference between 16 bit and 32 bit in PC land.

The StrongArm can run in both 26bit and 32 bit modes. If RO was 32bit compatible it would have little or no performance advantage over the 26 bit version. You gain a couple of instructions in 32 bit mode but they could equally have been added to 26 bit mode by intel if they had wanted.

The move from 16 to 32 bit in PC land was a move from 16bit to 32bit instructions whereas the move from 26bit to 32bit mode just allows the ARM processor to access more memory (2^32 bytes instead of 2^26) the instructions in both modes are 32bit and virtually identical which is why you can write a program which will work in both modes.

32bit Apps will not run on an arm2 unless they are written to be 26bit compatible.

I think the term 26 bit and 32 bit being used to describe the modes
is, I think, a bad idea, it makes people think there is a big difference.

The press release implied that the 32bit developers kit produced neutral code.

If something was written that relied on the 32 bit mode, it could still run on any machine capable of running RO4.

The Arm 2 is a 32 bit chip by the normal definition.

I think the term 26 bit and 32 bit being used to describe the modes
is, I think, a bad idea, it makes people think there is a big difference.

The press release implied that the 32bit developers kit produced neutral code.

If something was written that relied on the 32 bit mode, it could still run on any machine capable of running RO4.

Which means any machine with an ARM6 or better (RPC,A7000 etc.) as these processors all have a 32 bit mode.

Which means any machine with an ARM6 or better (RPC,A7000 etc.) as these processors all have a 32 bit mode.

Which in turn, if correct, renders the reason not to move to a full 32bit RISC OS even more invalid, all of the latest computers can run the full 32 bit OS already! Isn't that dedication enough?

The problem is existing progams won't work in a 32 RO without modification

Which means any machine with an ARM6 or better (RPC,A7000 etc.) as these processors all have a 32 bit mode.

Which in turn, if correct, renders the reason not to move to a full 32bit RISC OS even more invalid, all of the latest c
omputers can run the full 32 bit OS already! Isn't that dedication enough?
I'm sorry but I'm beginning to see more and more things wrong with that rather stupid leaflet handed out at Wakefield in
May :(

Why? An XScale compatible version of the OS, would do nothing for existing systems, other that give the potential for an
XScale upgrade for a Risc PC.

No amount of programming will make up for the deficiency in speed off a Strongarm and ports are going to get slower and slower as writers on other platforms don't bother optimising their programs for speed.

Take !pdf, thats a port of a xpdf. Some pages can take 16 seconds or more on a SA to render That would need a seriously fast machine to bring it down to a reasonable time.

Similarly when printing wouldn't you like your machine to be frozen for only 1/4 of the time?

And isn't decent printing one of the things select is supposed to deliver?

(I'm not saying we don't want an XScale compatible version of RISC OS, but ROL's inaction in producing it make sense
until Omega's with XScale start shipping.)

Any tinkerings will result in a little bit more XScale compatible code.

And isn't decent printing one of the things select is supposed to deliver?

(I'm not saying we don't want an XScale compatible version of RISC OS, but ROL's inaction in producing it make sense
until Omega's with XScale start shipping.)

If RO ltd produce a 32 bit OS then no-one uses it then it folds and RO dies that's ok as we would be no worse of than we would be with a 26 bit OS and 100 years of tinkering.

The longer they delay the more uneconomical they make it as more people leave the platform.

Omega's ability to utilise an XScale on the current OS will allow the apps that would be needed and give a pretty much
guaranteed market for the OS. (Given the very poor uptake of OS 4, would OS 5 sell for existing machines?)

However if ROL have no plans to re-asses the situation a couple of months after the launch of the Omega, then all the cr
itisism is justified.

(being curious, not belligerent)

I know there are people who use BASIC and there is always the argument of using ARM to speed things up. It's a valid point but I'd rather use a language that isn't really any more difficult and requires "less speeding up". If people really perceive C as difficult then try Ada - I did a couple of years of it at University and it's not bad (a bit long winded for my liking) - lots of BASIC like "procedure" this and "function" that. After that comment I should point out that Ada has many advantages over BASIC as well and is powerful.

At the end of the day I believe in the correct tool for the job - actually I love Java for this but unfortunately we don't have it. However I don't believe that writing almost 100% ARM code apps is productive and it has left us in the situation where even relatively modern software is going to fail if we go to a 32bit OS as opposed to just recompiling it (ok so you need the source code for this).

Writing in pure assembler does take longer - it takes longer to write, longer to debug, it's more difficult to maintain and extend the code. Part of the reason we've been left behind in the software race is because of this ARM code mentality. At work I often write several hundred working lines of Java code / day and C isn't far behind. This doesn't happen when I write ARM.

Which means any machine with an ARM6 or better (RPC,A7000 etc.) as these processors all have a 32 bit mode.

Which in turn, if correct, renders the reason not to move to a full 32bit RISC OS even more invalid, all of the latest c
omputers can run the full 32 bit OS already! Isn't that dedication enough?
I'm sorry but I'm beginning to see more and more things wrong with that rather stupid leaflet handed out at Wakefield in
May

Which means any machine with an ARM6 or better (RPC,A7000 etc.) as these processors all have a 32 bit mode.

Which in turn, if correct, renders the reason not to move to a full 32bit RISC OS even more invalid, all of the latest computers can run the full 32 bit OS already! Isn't that dedication enough?

I'm sorry but I'm beginning to see more and more things wrong with that rather stupid leaflet handed out at Wakefield in May

Which means any machine with an ARM6 or better (RPC,A7000 etc.) as these processors all have a 32 bit mode.

Which in turn, if correct, renders the reason not to move to a full 32bit RISC OS even more invalid, all of the latest computers can run the full 32 bit OS already! Isn't that dedication enough?
I'm sorry but I'm beginning to see more and more things wrong with that rather stupid leaflet handed out at Wakefield in
May

Why? An XScale compatible version of the OS, would do nothing for existing systems, other that give the potential for an XScale upgrade for a Risc PC.

True, existing systems would not benefit but it would work to prepare the market for the faster 32bit only processors that will eventually take over and not leave a huge stop gap once the market is ready to move on while waiting for RISCOS Ltd. to produce a version that will work on the newer processors. That time is not far off if the market will move on at all. I'm quite certain that Castle, RiscStation and even Explan would be very interested in using XScale or ARM10 in their future computers. Not having any work being done on the 32bit version isn't very encouraging to them.
Paul Middleton stated that there are many man-months required to convert the OS to 32bit, that time will not be any shorter if it's delayed! If the conversion had been slowed down instead of postponed completely until RISCOS Ltd. felt it was right to continue things would look a bit better.

But I do agree with Paul on one thing, a 32bit ready development tool has to come ASAP to allow developers time to get their products ready for the transition that will have to take place.

But I do agree with Paul on one thing, a 32bit ready development tool has to come ASAP to allow developers time to get their products ready for the transition that will have to take place.

They're downloadable from the RISC OS Ltd website - Pace made the beta version available sometime ago now. Hell Pace are already running a 32bit version of Techwriter.

Part of the problem is the insistence of everyone to still code in ARM code. C'mon peeps you surely can't have THAT much time on your hands?