this is a page about it:

http://news.cnet.com/news/0-1003-200-2592842.html

[Edited by tfountain at 18:10, 2/11/2000. Made link clickable]

[Edited by Matrix at 15:56, 25/8/2000]

[Edited by Matrix at 15:58, 25/8/2000]

The demoed version was at 800MHz and reading from the Intel site benchmark graph it should be around 3 times faster than a 233MHz SA-110.

[Edited by ams at 16:24, 27/8/2000]

[Edited by ams at 19:20, 29/8/2000]

The processor has not been the bottleneck on the RPC - the old IOMD was. Imago should be very well placed to take advantage of the higher speed ARM V5T designs (such as Intels XScale).

Processing wise we're probably looking at 4-5 times the processing speed (doing in register rather than I/O stuff). The imago has a bus bandwidth far faster than most PC's, if XScale (the 1GHz ARM) has a fast enough bus we may see better improvement in I/O speed as well.

As to comparing a RPC or other Acornoids to a PC the subjective performance of Acorn style equipment is a lot better compared to the PC than the clock rates might indicate.

Now with a 1GHz SA and a fast memory subsystem (like the 100MHz/128 bit Imago) there is no reason a 1GHz SA-2 (ok Intel XScale) could not outperform a PC on integer tasks and general operations by at least a factor of 2.

Or, the very nice Mr Pace might stick his thumb in.

As most Acorn type computers have the processor on daughterboards it (perhaps) would be less traumatic to fit an xScale processor. The incompatibility is at the voltage levels (on the xScale they are very much lower than on the RPC or Imago motherboards). But that does not prevent some enterprising organisation fitting one to a daughterboard with appropriate voltage level translators in place. After all most PC's use a mix of 3.3V and 5V components and it all seems (somehow) to work.

True if the processor uses a 100MHz bus it will be somewhat slower at I/O if plugged into a 16MHz RiscPC IOMD bus but it will come closer to its potential in the Millipede Imago (Imago in addition to a soldered in SA-1 has a daughterboard connector for precisely this situation) that bus will probably run at least at 64MHz while main ram runs at 100 MHz (possibly faster) over a 128 bit bus thus xScale could run (but with not much improvement in I/O) on a modified daughter card on an RPC or (with very much faster I/O) on an Imago.

At the least we will see faster processing (around x3-4 integer) and slightly faster I/O (on the RPC via a modified daughter card (like the Kinetic)) or much faster I/O on a fast wide bus on the Millipede Graphics Imago. A bonus for Imago (as far as I know) its FPGA chipset is configured to look like a darned fast IOMD with enhanced capabilities (it should NOT be a big problem to get RiscOS up to speed on it).

As for changes in the ROM addresses, this should not occur (the xScale in spite of Intel's cleverness is still an ARM V5TE architecture) and no inordinate changes should be required. I suspect we will see xScale used with the existing IOMD (or a derivative thereof) or the enhanced functionality in the Imago. The only thing xScale will require software wise is 32 bit clean coding in ROS to run. Bear in mind most ARM6XX, 7XX and SA-1's spend most of their time in their 32 bit (rather than 26 bit) configuration and only switch to a 26 bit mode when handling interrupts (even then its just done to produce results that 26 bit software can handle). This means the whole of the OS does not have to be re-written only non-user mode, flag manipulating stuff needs to. So I'd say with new hardware from Millipede, possibly RiscStation and Castle things are looking good. If I were a betting man I'd say Millipede or (perhaps) Castle have hardware compatible with xScale first. Think of it the Kinetic board could be redesigned to take an xScale (it already allows for 66MHz SDRAM so why not 100 and a new processor). The Millipede has the processor upgrade slot again opening possibilities. In the case of RiscStation they would need a whole new motherboard and (if they want RiscOS running on it quickly) an IOMD style chip.

As to the use of SIMD instructions these should only be used if they can be emulated on other ARMs (probably from RiscOS) so that a common software API is available to all vendors (otherwise we run the dangers of version incompatabilities of the sort rampant in Windows-land !)

About HP and Compaq boards, Paulo, do you know something we don't ??????

Intel seems to have problems at the moment with the adoption of RAMBUS (its preferred memory architecture). Partly this is because of the problems with Intels i820 chipset but also the very high cost of the RAMBUS/RDRAM. It has also been noted that the performance is really not all that much better (perhaps because the sort of processing Windows requires is NOT the sort that lends itself to RDRAM).

A better option might be DDR RAM which has better support and a price between that of SDRAM (cheap) and RDRAM/RAMBUS (very expensive). Please also remember the Imago board uses re-programmable FPGA circuits - so Imago offers a more configurable set up than that of a custom/ASIC set up. Perhaps Imago in future may implement an interface for 266MHz DDR ram.

The xScale would fit nicely into the expansion co-processor socket on the Imago, it runs at a bus speed of 100MHz and would (in effect) be using just 25% of the available bandwidth - the limit would not be the Imago but the processor itself.

Please note as well RiscOS is hiring a technical director to work with (quote) "contractors" on RiscOS development - good news indeed, so perhaps a 32 bit OS is not as far off as we thought !

[Edited by ams at 14:49, 29/9/2000]

I point to the current recall by Intel of the Pentium III 1.13GHz which is unreliable (it can't remain up long enough to compile the Linux kernel). I could be churlish and point to the original Pentium-60's divide problem, the 486 executing data out of order from its cache, the 386 not being able to multiply. But hey I thought I'd go easy so I won't

And they run on an OS with 64000 bugs (Microsofts own comment on Windows 2000). I see the first service pack for 2000 is out. now... so maybe the bug count has come down

And now Intels new xScale will they get this one right - I sure hope so. But there is always the ARM-10 if they don't.

In improving RISC OS its probably best to look at what is needed rather than what everyone else does. Firstly a move to 32 bit (for no other reason so we can run the newer processors), faster memory subsystem (Imago/Kinetic and Evolution do address this), faster I/O subsystem (Imago and Evolution) support for FP hardware (this will depend on 32 bit and the provision on the motherboard for processor upgrading). As to a server subsystem that depends on what you mean, I suspect most people don't need it. Multimedia will depend on the provision of fast I/O and (probably) FP (or at least DSP) as well as sensible OS support. Protected memory already exists under RISC OS user mode, its just a matter of only putting trusted code in non-user modes.

Overall I am optimistic, and will be more so when I see the new hardware

[Edited by ams at 18:32, 3/10/2000]

Very exciting (potentially) but not without some serious problems, not least of which, is there currently sufficient software development capacity in the RISC OS market to justify such a beast? I would like to think so...

ROR

I had a chance to see an xscale (I80200) module on the Millipede stand. Richard Jozefowski indicated that they hoped to include the chip in their design (in fact a sample PCB with an xscale daughtercard fitted was on the middle of the stand).

The working SA-110 based motherboards were up and running a scrollable backdrop, RiscOS was (as yet) not fully ported. If seeing a better than 1 megapixel image scrolled without any flicker impresses you then the Imago would indeed impress. Although it was not running RISC OS the clarity and movement of the image was impressive, it also shows that an ARM even at 233MHz without the impediment of a 16MHz bus can really delivery excellent performance.

The other major news item was the Omega from Mico (who had been keeping a rather low profile). This runs an SA-110 at 287MHz using a PC133 (133MHz memory bus) and using PCI as the I/O system (32 bits by 33MHz). Judging from their promo material (and the current Acorn User) I suspect they may ship before RiscStations "Evolution".

I did not see an actual incarnation at the show. I suspect they should have shown even a prototype (with caviats and warnings) as that would convince people of the non vapourwaredness of the product (ie., they should have taken a leaf out of Millipede's book).

Where does this leave RiscStations Evolution. I believe their spec was for a 64 bit PCI bus (not the usual 32) this would cast it more high end than the Mico, perhaps that is what they've aimed for, if they delay it may be the only niche open to them !

I suspect high end hardware is what will rejuvinate the market and should spur sales of RiscOS 4.5 when it comes along mid next year.

[Edited by ams at 19:28, 5/11/2000]

The chip inside a RISC OS machine? Probably.

The chip running RISC OS? No.

Be realistic, RISC OS Ltd have already announced the next upgrade to RISC OS. 4.5 isn't due to appear until summer next year and it won't be fully 32bit so I doubt it will be able to run on those processors. I'd be incredibly surprised if it ran on a normal SA and allowed apps to execute on an XScale and I personally think that the effort expended in making this happen would be better spent getting RISC OS 5 out.

So maybe Xmas next year unless Pace put in a whirlwind effort and RISC OS Ltd can ride on the back of it.

Either way, before those chips appear application authors have to know the ins and outs of writing 32bit code. C code is easily sorted - it's just a case of changing a compiler switch - but we also need 32bit versions of the shared C library etc (although I hear a rumour that there might actually be an announcement on this soonish).

One thing that everyone seems to have forgotten is that the development tools (ie compiler) won't run on a 32bit processor. GCC isn't an option if you have a module written in C and I can only hope the Zap and StrongEd teams are already on the case. However as for Norcroft, well I can't get my hands on even the current latest versions, will I be able to get the 32bit version?

WWW support is vital to Pace isn't it, so it's bound to have improvements in this sort of area, which is good. HTML 3.2 is getting a bit long in the tooth now...

I must admit I agree with a good deal of what you say. I've had a chance to peruse the datasheets on the xScale and can say some work will be needed to get it running under RiscOS.

It apparently can address a 64bit databus (loading in effect 2 32 bit words at the one time) and this will need to be addressed in both the Imago and the new Omega. The imago will offer better bandwidth (although both will run xScale at its limits, it's just Imago should have more spare bandwidth).

It differs from the SA-110 in a number of ways and I can see some headaches for the hardware vendors. It also allows for out of order execution (assuming there are no dependencies) and in many instances should be faster than the SA-110 (where its slower the xScale's faster clock rate should compensate).

I would caution against too much use of SIMD in that these operations are NOT supported by other ARM processors and code written to use them will not run on SA-110 or earlier processors. If SIMD is to be used there should be a "software" emulated implementation for older ARMs (at the expense of speed).

We need to be careful of Intel/Microsoft "Embrace and Extend" where you wind up with a number of subtly incompatible systems (ARM10's may offer better FP than xScale but we may lose the ability to use this if we build code for just xScale). Also some ARM9 and 10's will have native Java support (this is NOT available in xScale) so developers and RiscOS should not "rule out" one architecture by using techniques that are not portable.

Mark

(p.s. will the Omega fix these problems???)

This is not to condemn the Omega, as a new piece of hardware it addresses the slow memory bus of the RPC (although not as effectively as the Imago). I for one would be quite happy to have an Omega, having said that I think some people expect a raft of hundreds of cheap PCI cards to suddenly be available for the RiscOS platform will be sorely dissapointed. At best I'd expect Microdigital to arrange for a PCI 10/100 baseT network card and driver and (somewhere down the line) a SCSI card. Any other developments (particularly for more complex cards like (say) Creatives DVD Encore card) would require the active assistance of the supplier (I just can't see a big supplier spending tens or hundreds of thousands on a potential market of a few hundred users).

If you're going to buy an Omega FINE, just don't expect 430 different PCI cards to be available for use on day one, and when some do appear expect to pay a premium.

[Edited by ams at 19:31, 5/11/2000]

Well, about is RISC OS a Server system? well if not why we have SCSI interface, Server SUITES like NAVAHO or SAMBA Server etc? experiments? well also if only experiment let me say that them are very good under RISC OS the only problem is the slowest data file transaction that the system have (also for the old motherboards i know) but also for the system structure you know Lee.

For the PCI, i still continue to say that an hardware compatibility is necessary so if someone will want plug a card and build the driver we will have new hardware also in low prices (there is someone that don't like this?)

For the processor discovering system, well yes Lee you are right but to not more time it will be necessary and so what we will do? 14 DIFFERENT RISC OS VERSIONS? well also in that case, with flash ROMs we can install the right version for our machine, i want remember that also the motherboards "will be" more than only one... (old story in the PC world)

For the system new structure... ok tell me... we have new VERY POWERFULL istructions (SIMD) new system BUS (64 bits 32 in and 32 out), new FP units (plural because will be also ARM10 FP unit), NEW motherboards "clocks" managerable by the processor (with the new SA till 133 Mhz), and we want still use the old concepts?
For jump in the new world the system need structures for be more STABLE, with protected memory if an application try to be "bad" and will crash we will not have problems with all the machine (in windows is not so only because of the both structures 16 and 32 bits not because the protected memory not function correctly), for debug an application (also for beginners) will be more easy etc... (too much advantages for forget it)

- Networking and Internet... well networking is very important also because internet is nothing else than a WAN (Wilde area Network) so RISC OS need to grow in that direction if it want use internet in a very usefull mode.

-(Mark quint) For the file transfer on internet (now) can be problems of speed only because we have to control all the TCP/IP protocol, for do that we need SNMP based structures (that RISC OS not have) so is very difficult to discover why RISC OS on internet is not the best system... (today control networks or only clients features on wan is a science ehehehe :-) )

(it's ok how i wrote now? please help me! eheheeh :-) )

[Edited by Matrix at 09:21, 6/11/2000]

1) the XSCale tecnology is different than the ARM10 technology.

2) the FP will be different and the new SA have new istruction (very powerfull)

3) the clock of the processor is interesting, different area chips

4) different board managing

5) also different system bus and cache management...

I think too much for not start tothink about a RISC OS like Linux (in the istallation process i mean)

I think (my opinion) this they can build the system arround the new processors (and boards) on a CD ROM with a flash ROM installer for the kernel and the most important modules like memory mng etc...

ALL the rest (system library either) on the HARD DISC, SIMD or ARM10 FP etc... will be maskerade by a standard FP manager (recompiled by the processor) and an Emulator (for SIMD istruction)

A satellite kernel 26 bits for old apps and of course the interface code could be on the HD so all the new features can downloaded by RISC OS ltd site (usually the graphics interface of a system grow faster than the kernel)

the 26 bit satellite kernel will let run all the old world like also old drivers etc...

what will happen at this point? well protected memory will be necessary you know (the system will crash frequently with old programs calling, specially with PD software) the multi-thread etc... will help the machine to not sleep during the new hardware access and old kernel applications running

but yes maybe we will see this too late, but so how they can resolve the OLD/NEW wolrd compatibility problem? :-S

1) Yes XScale is different from ARM10 BUT it's compatible with the ARM V5 architecture. THe processor isn't that much different, it's just the SIMD instructions that have been added. This means that if the OS doesn't make internal use of the SIMD instructions it should run on both XScale and ARM10.

2) XScale doesn't have FP does it? Certainly I was under the impression that it didn't

I can't comment on 3,4 and 5 because I don't pretend to understand the finer details of the hardware. I just assumed that these issues wouldn't matter to the OS if the processor is ARM V5 compatible. Obviously this could be different if you want to optimise for games say.

I agree that there is potential to hide these differences. As you say one could write an FP module for machines without FP, ARM10s and XScale (using SIMD). Whether the effort can be justified is the real sticking point. I hope it can.

26bit compatability? A real problem. Personally if an emulator can be written easily then it should be done. Old apps won't run at StrongARM speeds but then at least you'll still be able to run them. If the Omega really can use the two processors to get around this problem it'll be great but I just can't see it myself, at least not supported in RISC OS directly.

1) The xscale and Arm10 are very similar in many respects (one is classified apparently ARM Architecture V5TE (basically ARM V5 Thumb Extended) and the other V5T). The extensions in xScale's case seems to revolve around SIMD and perhaps the bus system (afaik).

Both are code compatible (apart from the SIMD extensions). Hardware wise the ARM10 supports the its own (very fast) optional Vector processor (VP- a type of FPU) while xScale supports (a yet unreleased) Intel Media Co-processor (probably some a cross between an FPU and DSP).

If developers stick to plain "vanilla" ARM code most things should work equivilently on both. Compared with the old SA there are some minor differences in terms of timing (some context switches are slower on xScale (its faster clock however compensates !) and also how the write buffer works.

In spite of the general "ARM" compatibility some work will probably be needed by low level hardware coders to update the O/S or apps (particularly where timing and order of writes are important - for example writing to a "memory address" may in fact be to a register in an I/O chip causing an interrupt to be acknowledged. Merging writes might cause a required repeditive write to the same address to be missed (and the I/O chip not be accessed correctly)).

I imagine this will be more of a problem for hardware designers using the chip rather than the average punter.

2) as you state xScale (and ARM10) do NOT have FP as standard. Both can have FP via an optional co-processor interface (32 bit).

3) Paolo, I assume you refer to the "speedstep" like technology of the xScale. This may allow the chip to be a "miser" when used in battery mode, but for most desktop users it makes no real difference (I imagine it does fit well into what Intel has in mind for it).

One late interesting development is that ARM are fitting native JAVA support to the ARM9 (with ARM10 to follow). Worry not ARM mode is also supported (the processor can switch on the fly between the two). Interestingly xScale will not have this, that is unless Intel chooses to license it (any bets folks ?).

If you're interested in the gory details of xScale they are to be found in http://developer.intel.com/design/intelxscale/ixm.htm
and a Acrobat document is available for download.

Enjoy .....

[Edited by ams at 19:57, 7/11/2000]

[Edited by ams at 20:00, 7/11/2000]

[Edited by ams at 20:09, 7/11/2000]

[Edited by ams at 20:16, 7/11/2000]

Regarding the FP calls they already are standardised, FPE passes on the correct calls to the low level FP hardware (if present), so at worst there may be an FPE for xScale FP and a different one for VP-10 (ARM 10's very fast FPU). Both will present the same high level abstraction to calling software so (should) require no changes to existing FPE compliant code, or so I hope.