|
forgive my infinite stupidity..... |
|
(16:10 14/2/2001) TonyS (17:35 14/2/2001) johnstlr (17:41 14/2/2001) The Doctor (19:15 14/2/2001) johnstlr (09:49 15/2/2001) weiss (22:59 17/2/2001) sloth (00:59 18/2/2001) johnstlr (11:04 18/2/2001) weiss (15:37 18/2/2001) johnstlr (16:30 18/2/2001) ams (16:40 18/2/2001) sloth (13:58 15/6/2002) johnstlr (13:58 15/6/2002)
|
|
sloth |
Message #626, posted at 16:10, 14/2/2001 |
Unregistered user
|
About 5 years ago i used to work for a small computer company writing risc os software. I read and article in some PC magzine about the new Omega and was quite excited.I thought RISC OS died a death years ago but have been looking around the internet and found all these acorn sites. Anyway, one thing about the new strongarms confused me - why do people keep saying that risc os is not 32bit? I thought all the ARM chips were 32bit through and through. How (and why) did acorn write a non 32bit operating system for chips that only had 32bit instructions? Or have i been mislead? I dabbled with arm assembler on the arm2/3 and i saw no indication that the instructions were anything but 32bit. but now i read an article that makes out the old strongarm is 26bit or something and the xscale is 32bit. can someone explain what this means? thanks |
|
[ Log in to reply ] |
|
TonyS |
Message #627, posted at 17:35, 14/2/2001, in reply to message #626 |
Unregistered user
|
The address bus is only 24 bits wide, the lowest 2 bits are always 0. If you need to access a particular byte the cpu does an automatic shift after loading the full word to leave only the byte you want. I guess a lot of programs were written with this in mind. |
|
[ Log in to reply ] |
|
johnstlr |
Message #628, posted at 17:41, 14/2/2001, in reply to message #627 |
Unregistered user
|
RISC OS is a 32bit OS but it makes use of a 24bit addressing mode built into earlier ARM processors. What this means is that the processor flags were stored in the top bits of the program counter. The 32bit addressing mode in later ARMs uses all the bits in the program counter to access the entire address range and the processor flags have been moved into a separate register. Unfortunately what this means is that where subroutines used to preserve the processor flags across calls simply by restoring the value of R14 into R15 at the end of a the subroutine they don't anymore. The effect is that any code which assumes this will run on the 32bit addressing mode but won't execute correctly. There's more to it than that but that's the main part of it. |
|
[ Log in to reply ] |
|
The Doctor |
Message #629, posted at 19:15, 14/2/2001, in reply to message #628 |
Unregistered user
|
As I understood it (in my limited way), The StrongArms are 32bit chips, with a 26bit mode. RISC OS seems to use this 26bit mode. The new X-Scale chips are also 32bit, but don't have the 26bit mode.Thats the basic situation as I understand it, someone correct me if I'm wrong. |
|
[ Log in to reply ] |
|
johnstlr |
Message #630, posted at 09:49, 15/2/2001, in reply to message #629 |
Unregistered user
|
Yeah sorry the 24bit is a typo - should read 26bit addressing mode and yes you're right the StrongARMs contain both 32bit and 26bit mode, as has every ARM processor from the ARM610. However the 26bit mode was dropped in the ARM9, ARM10 and XScale so the space on the silicon could be used for the Thumb architecture |
|
[ Log in to reply ] |
|
weiss |
Message #631, posted at 22:59, 17/2/2001, in reply to message #630 |
Unregistered user
|
Honest question: Why bother? What are the benefits? |
|
[ Log in to reply ] |
|
sloth |
Message #632, posted at 00:59, 18/2/2001, in reply to message #631 |
Unregistered user
|
so when this omega comes out, the OS will only run on the strongarm chip, and when you install an xscale on a daughterboard it will be ignored (except by dedicated progs)?or did i read that it transforms instructions and passes them on? is that what the chipset they're waiting for does? (sorry i can't remember what i read but i cant find it anymore.) how big is the code for risc os 4? can't risc os ltd just adjust it for 32bit memory access? (that may seem like a naive question, but i don't know how much of a feat that would be) hmm - couldn't you write a code translator that converts old ARM code? Then they could run it over the risc os source code. james PS. seems to me intel have been polluting the elegant ARM RISC architecture with thumbs and flag registers ;p |
|
[ Log in to reply ] |
|
johnstlr |
Message #633, posted at 11:04, 18/2/2001, in reply to message #632 |
Unregistered user
|
Thomas: What are the benefits of what? I'm not sure what you're asking. The benefits of 32bit mode are simple - larger address space with memory capacity up to about 4gig. The benefits of the Thumb architecture is that it can compress the ARM instruction set to work across a 16bit bus which, IIRC, saves them over a third of memory space. Bear in mind that ARMs target market is small, embeddable systems (car engines, mobile phones etc etc) and these saving have real benefits. Everything ARM does is for the embedded / small systems market. The fact that they make pretty good processors for desktop machines too is irrelevant to them. James: Apparently part of the Omega custom chipset is capable of detecting whether the code / data being executed operates in 26 or 32 bit mode and switch it through the approriate processor. Therefore, in theory RISC OS 4.5 could run on the StrongARM while the 32bit version of Easiwriter would run on the XScale. Of course no one outside Microdigital has seen this working yet. The chips required to do this may be the reason for the delay but remember that the Lightning graphics chip is also "custom". All this was documented in December 2000 Acorn User. How big is RISC OS 4? Source code several hundred megabytes. Binary? Well it all fits in those ROMS so less than 8MB. Pace are adjusting it for the 32bit architecture but it's a huge job and one that has been discussed on the newsgroups many times. Basically if you consider that 99% of the source code is ARM assembler and it has to be checked by hand... A code translator is difficult and wouldn't solve all the problems. Firstly it's difficult to detect all the instruction sequences that can cause problems. I don't pretend to understand the details of this - it should be archived under deja (or rather google now) somewhere. Secondly it wouldn't solve the problem with all the applications that will break, especially as the source code isn't available for most of them. From the snippets I've interpreted on the newsgroups it would seem that some sort of emulator / JIT interpreter is being investigated for old apps but they will suffer a large performance loss. Finally Intel have nothing to do with the Thumb architecture and Flag registers. They were necessary for ARMs target market. Please remember that, as I said above, the RISC OS market is insignificant to them. Intel have of course added instructions for DSP processing and the like. |
|
[ Log in to reply ] |
|
weiss |
Message #634, posted at 15:37, 18/2/2001, in reply to message #633 |
Unregistered user
|
Thought it'd be like that - we need to move to the 32-bit architecture to take advantage of the development that's going on...not really because we want to for our own benefit... |
|
[ Log in to reply ] |
|
johnstlr |
Message #635, posted at 16:30, 18/2/2001, in reply to message #634 |
Unregistered user
|
But it is for our benefit as well. Consider the fact that wimpslots are limited to 28MB and applications have to use dynamic areas to store data in. IIRC this is purely because of the addressing scheme currently used by RISC OS. On a 32bit architecture we can have a flat 4gig address space and we don't have to worry about hacks such as dynamic areas. Other benefits include the continued development of the ARM processor. If ARM is not successful in its target market the ARM will disappear and then we won't even have a processor to run RISC OS on. Converting RISC OS to another processor just isn't feasible at this point. It may become more so if Pace rewrite chunks of it in C as they go along but I doubt we'll ever see it. Pace (and ourselves) also need access to the faster processors. RISC OS will never make it as a large desktop system in its own right under current circumstances. However if RISC OS STBs are successful (note Pace have other options and use them) then you get more leverage for RISC OS development on and off the desktop. Personally speaking I'd love to get my hands on an ARM10 with the floating point unit. Ok we're getting XScale but they're both ARM V5 architecture chips so they should be swappable to some extent. Acorn should have made the jump to the 32 bit mode with the release of the ARM610. The fact that they chose not to is the reason that we're in the mess we are now. It is being addressed though. |
|
[ Log in to reply ] |
|
ams |
Message #636, posted at 16:40, 18/2/2001, in reply to message #634 |
Unregistered user
|
Like everything it has its upside and its downside. The upside is you can have programs as big as you like (well up to several gigs), although you'd probably be hardpressed to find one that uses more than a few megs. The downside (not often commented on) is the fact the original ARM ISA had the combined PSR and PC was so that you could change processor modes and preserve the flags AND program counter with one instruction. The neat thing is you could also restore them with one instruction. This made the ARM very fast at handling interrupts (something Acorn really wanted when this was coded in). A side effect, however, was when you try to access an address greater than 2^26-1 bytes you'd get an Address exception. So all your code and data had to reside below 64MBytes (in the days Acorn designed ARM even a memory hungry PC used only 8-16MBytes of RAM so the memory restriction seemed unimportant compared to the improved interrupt handling). Now things are different. At one level I can symphatise with the view Thomas expresses, in performance terms 32 bit will slow the ARM slightly when handling mode changes (on the other hand high clock rate ARMs will only run in 32 bit mode). I think this is one of those cases where you have to grin and bear it. |
|
[ Log in to reply ] |
|
sloth |
Message #637, posted at 13:58, 15/6/2002, in reply to message #636 |
Unregistered user
|
what is easiwriter? a word processor? so the chipset redirects 32bit apps to the xscale and 26bit apps to the strongarm. So would you need this JIT compiler thing then? and if they released a 32bit risc os, and you only ran 32bits apps (not a realistic scenario at this stage i know) would the strongarm never get used? Or, more realistically if you ran risc os 4 and only 26 bit apps then an xscale would do you no good whatsoever? how many 32bit risc os apps are there? is there a 32bit risc os c compiler yet? how long has this thumb thing been around then? since they started using arms for embedded systems? (its just i never heard of it till now) does xscale have an FPU? which ARMs do? it would be interesting to see the relative performance of the various ARMs against PC chips (i know these things can be misleading, but just out of curiosity) sorry for just asking a bunch of annoying questions, but at least it provokes debate james PS, sorry - didn't realise thumb etc were nothing to do with intel - for some reason i got the horrific notion into my head that intel had BOUGHT arm *shudder* |
|
[ Log in to reply ] |
|
johnstlr |
Message #638, posted at 13:58, 15/6/2002, in reply to message #637 |
Unregistered user
|
what is easiwriter? a word processor? It is not a wordprocessor it is THE wordprocessor. Word may be more powerful is some aspects but Easiwriter is a class piece of software. I'm writing my thesis on it using an A4000 over a PII 366 laptop with Word. Nuff said. so the chipset redirects 32bit apps to the xscale and 26bit apps to the strongarm. That is what has been proposed for Omega. Obviously none of us have seen this working. So would you need this JIT compiler thing then? Maybe I should explain the terminology. JIT stands for "Just In Time". It's a concept used a lot in Java to turn Java bytecode into native machine code just before it executues (thus improving execution speed). Therefore you get the "Just In Time" concept because the process is carried out just in time to be worthwhile. The same thing has been proposed to modify 26bit ARM apps to run on the 32bit addressing mode, although it's a lot harder to achieve. The reason is has been suggested is that it will offer better performance than just purely emulating the 26bit environment. It is is needed because the Omega is unique in having the two processors and the custom chipset. Evolution probably won't and I doubt Imago will have either. and if they released a 32bit risc os, and you only ran 32bits apps (not a realistic scenario at this stage i know) would the strongarm never get used? Or, more realistically if you ran risc os 4 and only 26 bit apps then an xscale would do you no good whatsoever? Under a 32bit RISC OS then in theory 26bit apps would still use the StrongARM. Whether this happens or not is another matter entirely. At this point though the StrongARM does become somewhat redundant. Secondly yes RISC OS 4 and 26bit apps cannot make use of an XScale at all, hence why the Omega doesn't ship with one (along with the fact they're not available yet) how many 32bit risc os apps are there? is there a 32bit risc os c compiler yet? Only a 32bit version of Easiwriter has been announced. I'd be surprised if other apps hadn't been compiled up though (for example Ovation Pro). The Norcroft compiler has been capable of generating 32bit since version 5 - so for about 6 years or so. However until recently we didn't have 32bit versions of the C libraries to go with it. Pace recently released a beta version to developers. how long has this thumb thing been around then? since they started using arms for embedded systems? (its just i never heard of it till now) Blimey IIRC Thumb predates StrongARM. Certainly it has been available since the ARM9 and the concept was around before that. While it has been mentioned in Acorn User it has little relevance to the RISC OS world so isn't mentioned that often. ARM has targetted embedded and low powered systems from the start, ie from when they were spun from Acorn. does xscale have an FPU? which ARMs do? XScale doesn't. The ARM7500FE has one and the ARM10 has an optional unit which is incompatible with the ARM7500FE unit (but also vastly superior) it would be interesting to see the relative performance of the various ARMs against PC chips (i know these things can be misleading, but just out of curiosity) I've heard that at 400Mhz the FPU in the ARM10 matches those on a 1Ghz PIII. How accurate this is I can't say. Additionally the ARM has always been superior at integer work at equivalent clock rates sorry for just asking a bunch of annoying questions, but at least it provokes debate The only stupid / annoying / (delete as appropriate) question is the one that isn't asked if you don't understand something. sorry - didn't realise thumb etc were nothing to do with intel - for some reason i got the horrific notion into my head that intel had BOUGHT arm *shudder* No, not at all - IIRC Intel actually have to license the ARM architecture from ARM. Of course they could completely destroy it but then they wouldn't be able to class it as an ARM processor. |
|
[ Log in to reply ] |
|
|