Ok I conceed this point. I guess translation would be better suitted as that is all that MS did (look at the BASICs if you do not believe me). They did NOT rewrite it only translated it from one instruction set to another with the exact same sequence of operation. Rewriting would mean changing something other than the opcodes.Heater wrote:"porting" has a quite specific meaning in the software world. It does not mean totally rewriting a program so as to get the same functionality on a different machine. It helps to try and use words in a way that that is commonly understood otherwise confusion reigns.
Wikipedia sums up "porting" nicely here http://en.wikipedia.org/wiki/Porting
By that definition no. Though it takes a lot less time to translate an application written in assembly to a new CPU than it does to do a rewrite. This is because you are not making any real changes when translating the assembly, yes in some cases you may have to make some small functional changes in order to maintain optimal operation, or deal with the difference in how things are done on the different platforms (though this is true of HLL stuff as well).Clearly assembler level programs are not portable. They have to be rewritten. That's may be OK if they are small, like early MS BASICs or CP/M but is not scalable to larger systems like Windows NT, BSD, Linux or the millions of applications that run on them.
Realy? Firstly i think you mean translate as a complete rewrite is unneeded just dumb translation.MSDOS, CP/M, RISC OS, early Mac operating systems and many others are fine examples of programs written in assembler that live or die with the architecture they were written for. No one is going to take the time and trouble to rewrite them for other devices. It's simply not worth the investment.
Secondly Mac OS was ported to the PowerPC. Yes Apple did cheat by using a 68k emulator to give themselfs more time to translate things over to PowerPC code, though with Mac OS 9.xx there is very little 68K code, it is almost 100% PowerPC code.
Mac OS died because Apple refused to continue it after promissing that they would never drop the classic Mac OS. That combined with the dissorginization of the Copeland project (Copeland would have been a worthy successor to Mac OS unlike the unixen Darwin based that Apple went with).
And CP/M? I have never seen a version written in assembler. I have seen the versions writen in HLLs and the ports to the 88000, z8000, 68000, 8086, etc. CP/M was originaly for the i8080.
And those are also greate example of oses that when used for day to day stuff using them from the local terminal and doing misc stuff allways have some trouble. They are greate OSes when applied to applications such as large scale automation, Network servers of verious types and such. Though for the user Facing OS they fall short, and for Embeded applications they fall way way short.NT, Linux, BSD and all those apps are fine examples of why the world uses higher level languages that can be recompiled and "ported" to whatever new technology comes along.
Yes and the way that Apple did it with the PowerPC versions of Mac OS and the 68LC040 emulator was the best way. There was no loss of old applications and it was truely seamles as the OS was the same for both the PowerPC And 68k apps. No need to run an entire OS under emulation.Legacy assembler codes can be kept on life support by creating emulators of the architecture they require. Hence all the game machine emulators that have been created.
I can not argue that. RISC OS is a greate OS and the ARM has become the most popular 32-bit CPU around.RISC OS is lucky in that the ARM became a success and it can now be run on devices like the Pi. Had the ARM disappeared like so many other processor designs then RISC OS would be gone. Apart from the dedicated software archaeologists who would write ARM emulators in order to run it.