That puzzled me as well until I thought that a complete application/module of machine code is clearly identifiable as 26bit or 32bit even if each individaul line is not. Therefore the ability to switch between 26bit and 32bit mode can be set for a section of code when it is loaded....

regards,

Firstly the discussion concerning 26bit execution. Ok I'll try and be more specific as to what I mean.

When windows went from win16 to win32 all that changed were some of the API calls. Some took new parameters, some of the parameters had new meanings. You can trap these because all you have to do is reimplement win16 as a wrapper around win32. This would be the equivalent of writing wrappers for SWI calls. However the important thing to note is that the x86 instruction set DIDN'T change.

We are faced with the problem that the fundamental language of the processor (ie ARM assembler) has changed. While 26bit ARM will run on a 32bit processor the result of executing each instruction will not necessarily be the same. The real problem is that the processor flags have been moved from the program counter (PC) to a separate register.

At the very least the affects ALL subroutine calls. It has also resulted in a change of the ARM Procedure Call Standard. At the moment the processor flags are saved when the return address is saved. However simply saving PC doesn't do this in 32bit mode, it just saves the return address. Any function which states that it saves the processor flags now doesn't. Any code which assumes that a function saves the processor flags will no longer work correctly. Because saving the processor flags requires an extra two calls the APCS has been altered to say that it is no longer necessary for a function to save the flags. This is completely incompatible with the old standard. C code is ok, it can be recompiled to take this into account, ARM has to be rewritten.

On top of this I believe there are other issues concerning changing the processor mode and certain instruction sequences. These instruction sequences cannot easily be detected automatically. If they could someone would have written the code to do it by now.

Therefore the Win32 method won't work for us. Merely stating whether a piece of code if 26 or 32 bits only allows 26 bit code to be detected and appropriate action taken. Assuming that new machines will not have processors that have 26bit modes then emulation is the only option. You can call it "interpretation" if you like, but if you're interpreting every instruction and then executing it in a new environment it is emulation. You are emulating the old 26bit environment.

Concerning the emulation of the Java extensions on processors which don't have them. Well this requires a Java VM and we still don't have an up to date one. Given how long Java has been around now I don't see that providing one for machines without the Java extensions is something that will happen very quickly.

Finally Internet drivers, and in particular USB. Well if there is a standard method of writing USB drivers then I believe the drivers will come. The problem is that none of the mainstream and hobbyist developers have access to USB hardware or the USB developers specification. So even if I could write a driver right now I can do nothing but twiddle my thumbs or perhaps experiment on Windows.

i guess to combat the 26bit problem, wouldnt it be easier to emulate the 26bit processor on the Xscale proccessor (its not like there's much processor requirements anyway for much 26bit apps)

Part of the problem is that we could indeed emulate the 26bit ARM in full on a 32 bit processor. The problem is it would make a massive hit on performance (even for ARM10 or xScale).

The real irritation is (as Lee mentions) the issue of flag saving. To all intents and purposes (probably) 99% of all ARM code would NOT need to change. (ARM32 bit and 26 bit is IDENTICAL except for R15 and the PSR (Flags)). But current methods need information sent back in flags and its dealt with very succinctly in Lee's article.

Bear in mind existing ARMs generally run in 32 bit configuration and "fudge" 26 bit mode when non-user modes are called, it all works without much of a hit because most of the rest of the time you can run ARM code without any veneers (a 32 bit or 26 bit ADD for example are identical and need not be handled differently).

A full emulation is a different kettle of fish. I used to do a some ARM assembler (years and years ago) and would like to get back into it. From my point of view I think it would be helpful if ROL specified standards for ARM code and 32 bit handling, a short article here perhaps, to specify what precautions coders should use when writing ARMcode and required changes to support RISC OS from now on.


[Edited by 144 at 18:56, 12/11/2000]

Unfortunalely ARM assembler is rather nice (and the executables are mouthwateringly quick) and it would be nice for those ARMcoders to have a chance to use the new hardware. I don't mind having separate macros for assembling 26 bit and 32 bit code if that's what it takes, so long as a standard method is established for calling and using 32 bit hardware.

[Edited by ams at 19:59, 13/11/2000]

[Edited by ams at 20:14, 13/11/2000]

So isnt this what should be built/fixed into RiscOS 5 - an OS specifically for the new proccessors, and also for the new machines such as the Omega and Evolution?? then u can put in drivers for USB, PCI cards etc...
that way, owners of these new machines wont be "held" back by current problems, and it will also "fix" the problem of most users wanting to keep what they've got, and not take a step forward, for which it is very important for this OS to do so.

The problem with this is it won't work on ROM code (it can't be modified, so RISC OS can't be fixed this way)

So isnt this what should be built/fixed into RiscOS 5 - an OS specifically for the new proccessors, and also for the new machines such as the Omega and Evolution?? then u can put in drivers for USB, PCI cards etc...
that way, owners of these new machines wont be "held" back by current problems, and it will also "fix" the problem of most users wanting to keep what they've got, and not take a step forward, for which it is very important for this OS to do so.

Mark as I said originally the solution I suggested would not fix ROM (it biggest drawback). I agree with you that the real solution is an OS directed towards the new hardware, the problem is people will still need (or want) to use their old 26 bit code. There are thousands of 26 bit apps and zero 32 bit ones, and some of the original vendors will not be willing to upgrade their code. A 32 bit OS that cannot run ANY 26 bit code can effectively be thought of as a new OS, and that will mean persuading (now sceptical) developers to support it. Users will find a library of thousands of programs reduced to just a handful of BBC BASIC programs that would run in any event. Some means of running 26 bit code is needed (be it emulation (ugh) or some exception trapping mechanism).

Dual processor machines like the Millipede or Omega may be able to address this by running the 26 bit code under the old SA-110.

I am not trying to be a stick in the mud on this, but people will be really miffed if there is no way to run their old apps at least under emulation (ugh) or by some more efficient means.

[Edited by ams at 19:47, 21/11/2000]

2) Up grading the Operating system, also this can be fixed useing FLASH ROMS, so RISC OS Ltd, can distribuite RISC OS on CD ROM it will be more faster and more cheap than the actual system

I seem to recall RISCOS Ltd. saying that a CD distribution of RISC OS was not to be because of agreement to Pace Ltd. It is possible that both will change their minds though.

I want replay to this old message for some particular reason, why buy RISC OS 4.5?
well...

1) because 4.2 and 4.3 need to have a new DMA Manager (too much bugs with the DMAManager)

2) because (if Risc OS will do this) 4.2 and 4.3 need a better configuration manager if you use a powertech SCSI the configuration manager not recognize it, and the powertech is the only one full 32 bit and UDMA SCSI 3 that we have)

4) because they need to fix the problem of PPP driver that is STILL a shareware and in all others operating systems PPP, TCP/IP and other network stuff are included! (also in Linux that is free!)

5) Because it need some more corrections about compatibility with old RISC OS versions so we can recover some old applications more

Why i answered about this question? easy because RISC OS basicaly need to grow in a way that will let use be used for the new system (32 bits i mean) and also that will give to us new instruments for be ready to the next step...

I agree with the Annraoi answer but i want remember that the new SA have a 64 bits system bus (32 in and 32 out) and all old ARM have a 32 bit system bus so this in hardware lever will make a lot of problems for put both the processors on the same board (without thinking about different clock's, cache , memory allocating, drivers for devices in 26 bits or 32 etc...) but anyway an old ARM could be used like a second processor for emulate old machine or for readress in in old application... but in that way will not be a lot of advantages from the new processors and also it will not be used for a lot of time...

The problem Paolo mentions concerning the 32 bit bus is not as problematic as it at first appears. Buffering and multiplexing/demultiplexing busses is a "known" science. Besides I've seen Imago running and its got a 128 bit bus, the SA-110 has a 32 bit bus and the video system may well take more of the 128 and the whole shebang runs at 100MHz bus speed (the SA-110 at 64, video at 100) its do-able so let's not get too worried about it.

The issue really is can we have a 32 bit OS that (in some way) allows older 26 bit software to also run (even at the expense of the older software running slower). This will be sufficient to encourage developers to make their code 32 bit and not so irritating as to drive existing users to other platforms.

Just one fly in the ointment though, what about people with RPC's or RiscStations are they faced with having to "bin" their equipment and buy a new machine so they can run 26/32 bit code ?

Is there any reason Riscos 5 couldn't support multiple threads on multiple processors, and allow 26 bit apps to run if 2
6 bit 2nd processor is fitted.

Just one fly in the ointment though, what about people with RPC's or RiscStations are they faced with having to "bin" their equipment and buy a new machine so they can run 26/32 bit code ?

Surely current StrongARM machines are quite capable of running 26/32 bit code? In which case users would require an OS upgrade at most.

Anyone with an ARM3 machine or less should really upgrade (and this includes me - I'm just waiting for the right machine). I personally don't see why application developers should support anything less than the ARM610 (maybe even ARM7500) anymore.

I personally don't see why application developers should support anything less than the ARM610 (maybe even ARM7500) anymore.

I couldn't agree more, developers should start to assume at least RISC OS v. 3.5 from users. If they continue to develop for 3.1 and older, applications will not have the freedom to evolve. Continuously trying to keep programs running on 4Mb computers or maybe even 2Mb is just getting a bit tight. Surely many programs don't need more than 2Mb of memory and will not need more but far too many programs will suffer with these restraints.
We want bigger and better games, running in 3D and fancy graphics and many want them on their A3000s!
I'm sorry but there comes a time when the user has face reality and buy a new computer to get better software and I think it's way overdue for many RISC OS users to upgrade their hardware. Hopefully the Omega, Evolution and Imago will make many users upgrade.

Gulli

great games (3D in particular)
top end art and modelling packages,
state of the art web browsing (including flash and java)

and others..

aren't practical on the lower end machines but if a developer doesn't make the software run on these machines they get slated by disgruntled users. Personally I wouldn't care about the views of these users and they're not representative of the people doing the buying.

I do agree though that where possible backward compatibility should be maintain. however I don't believe any developer should spend time making it happen. If it works, great, if not well, it has been over 10 years since the ARM2 first arrived.

[Edited by johnstlr at 22:22, 29/11/2000]

The problem is that a lot of the things that people want, ie

great games (3D in particular)
top end art and modelling packages,
state of the art web browsing (including flash and java)

and others..

aren't practical on the lower end machines but if a developer doesn't make the software run on these machines they get slated by disgruntled users. Personally I wouldn't care about the views of these users and they're not representative of the people doing the buying.

May I just say that SunBurst was slagged off because it used lo-res graphics so it could be ran on ARM2 upwards and I have had a few emails slagging EMD off because it only works on SA RPC's. You can't win, forget these stupid people. If you have a package that could easily work on older machines then do it but at VOTI we code games for the computer systems we use, we then see if it can run on lesser machines, if it won't or requires too much work then we won't bother.

You can't win, forget these stupid people. If you have a package that could easily work on older machines then do it but at VOTI we code games for the computer systems we use, we then see if it can run on lesser machines, if it won't or requires too much work then we won't bother.

Quite right too.

People (even after 32 bit introduction) will still need old applications that are no longer being developed (but that are still useful). Or do we just say bye-bye to Artworks, ABC and a raft of other useful apps.

That point can only be addressed feasibly in one way - that of allowing backward compatibility for old code (that may mean dynamic translation or emulation or trapping illegal 26 bit flag ops). The only alternative is (somehow) that the original developers release source code for their apps and allow them to be updated (fat chance of that I think)

Old code will run slower than new code (and users will be aware of this) so it will promote sales of new (32 bit) software and also new hardware that best utilitises the new 32bit stuff.
Lack of support for 26bit code will make people loath to lose the occasional use of some long used software and that might deter them from investing in new hardware and software which would be detremental to the RISC OS community as a whole.

hmmm possibly, but there woudl be more users to buy the software, & it would save me having to "find" some money to buy an Omega :)

Ah, Omega, Omega... has anyone seen proof that it works yet? Weren't they supposed to be shipping yesterday or something?

Re: ChiOS

RISC OS on a card is a mad idea that sounds the end of RISC OS.

Absolutely, I agree. Not nice at all...

Well if that were the case they would be at a disadvantage compared to Castle wouldn't they (assuming the Castle machine had both PCI and Podule busses). In addition Podule bus is (actually) simpler than PCI (as well as being slower). PCI chipsets (on the other hand) are notoriously "pickey". I recall a review of an Athlon board using a well known brand of PCI chipset (I shall not name the guilty !) and it refuses to operate with a certain brand of soundcard (and this problem is documented). I doubt if MD or RiscStation are going to develope a PCI chipset, so they will (no doubt) be relying on someone elses.

Standard though PCI is it is not faultless, some implementations are flakey. It is difficult to design hardware to run using it. Developing drivers for PCI can be more expensive than developing new hardware and a driver for a simpler bus (like Podule). Lee is right we don't need to design the hardware add ons, but you need to fully understand them to write the drivers. Now if these are proprietry designs from large corporates they may not be willing to provide details or assistance (at least not without charging for it). If the details are not available either dodgy drivers or no drivers is what results.

The difficulty of implementing PCI (+Drivers) should not be underestimated nor should we overestimate the advantage having PCI will give. Yes you may have cheaper PCI 100 BaseT cards and (later) a UW-SCSI card but that's it. No soundblaster, no fast 3D accelerators (most are AGP anyway and having PCI don't help there), no Creative Encore DVD, etc., That is unless a LOT of RiscOS boxes get sold with PCI in and a market established that attracts the like of Creative and others.

Having PCI is useful in as much as its an "advertising" bullet point, in practical terms other than for NICs and cheap UW-SCSI cards it serves no other purpose. We should really aim higher, for more advanced bus structures that allow higher speed than PCI or Podule allow. If we've already chosen non-standard hardware why do it by halfs ?

[Edited by ams at 19:35, 9/12/2000]

We should really aim higher, for more advanced bus structures that allow higher speed than PCI or Podule allow. If we've already chosen non-standard hardware why do it by halfs ?

All very good points you make here but not being very hardware minded, are there any faster more reliable bus structures available or is this a matter of creating a new type of bus structure?

If the latter is the case I think PCI is the only option for the simple fact that the bus exists, much information about it is readily available and solutions to many problems that might come up have already been solved and are accessible from various sources such as Intel and others. Even lots of hardware for PCI cards is available off the shelf.

If on the other hand a better and faster bus structure is readily available and doesn't cost an arm and a leg maybe that's the way to go but that doesn't seem to be what the developers are ready to do or what the users want and they are who in the end, wether people like it or not, the people that pays for the products.

PCI has become the buzz word in RISC OS land (right up there with XScale) and many people see that as the only solution to all our problems. True, it could help out a lot but the mere existance of a RISC OS computer with a PCI bus doesn't get hardware and drivers up and running but the fact remains that developers that develop PCI cards are a penny a dozen so getting someone to help with writing drivers and developing hardware could be as easy as writing an e-mail!

Gulli

Lee previously pointed out that it would be good if Castle produced a machine that supported PCI/USB and Podule bus but that Microdigital and RiscStation do not need to.

Well if that were the case they would be at a disadvantage compared to Castle wouldn't they (assuming the Castle machine had both PCI and Podule busses).

Possibly for RiscStation. However I suspect if Omega appears on time it could clean up regardless.

In addition Podule bus is (actually) simpler than PCI (as well as being slower). PCI chipsets (on the other hand) are notoriously "pickey". I recall a review of an Athlon board using a well known brand of PCI chipset (I shall not name the guilty !) and it refuses to operate with a certain brand of soundcard (and this problem is documented). I doubt if MD or RiscStation are going to develope a PCI chipset, so they will (no doubt) be relying on someone elses.

Yes, I remember talking to Simtec at Wakefield and they pointed out that one of the problems they'd had with Evolution was 2 PCI chipsets not actually fully conforming to the PCI spec. However I was also left with the impression that they'd cracked it.

Standard though PCI is it is not faultless, some implementations are flakey. It is difficult to design hardware to run using it. Developing drivers for PCI can be more expensive than developing new hardware and a driver for a simpler bus (like Podule). Lee is right we don't need to design the hardware add ons, but you need to fully understand them to write the drivers. Now if these are proprietry designs from large corporates they may not be willing to provide details or assistance (at least not without charging for it). If the details are not available either dodgy drivers or no drivers is what results.

Again these are potential problems but it can also be looked at another way. Writing a PCI driver will be difficult, there are no two ways about it, but from a personal point of view, it's merely a case of getting to grips with the information and writing the code. Creating hardware is completely beyond me. One is a very difficult task, which may or may not get carried out, the other is simply impossible.

The difficulty of implementing PCI (+Drivers) should not be underestimated nor should we overestimate the advantage having PCI will give. Yes you may have cheaper PCI 100 BaseT cards and (later) a UW-SCSI card but that's it. No soundblaster, no fast 3D accelerators (most are AGP anyway and having PCI don't help there), no Creative Encore DVD, etc., That is unless a LOT of RiscOS boxes get sold with PCI in and a market established that attracts the like of Creative and others.

But under the current system we can't even get UW-SCSI or cheaper Ethernet. As for 3D cards, yes most are AGP although 3DFX still produce PCI Voodoo cards. Admittedly there is no way of telling how much longer they will continue to do so. Also why can't we get soundblaster, or at least soundblaster compatible? Aren't soundblaster compatible ISA cards available the RiscStation 7500? Surely if the information for creating a driver for them is available they will be for the PCI variant (unless, as you say, a proprietry chipset has been used)

Having PCI is useful in as much as its an "advertising" bullet point, in practical terms other than for NICs and cheap UW-SCSI cards it serves no other purpose. We should really aim higher, for more advanced bus structures that allow higher speed than PCI or Podule allow. If we've already chosen non-standard hardware why do it by halfs ?

Suggestions? This isn't a field I know too much about so I'm not aware of many alternatives past Microdigitals MicroBus and Millipedes souped up podules.