User avatar
DavidS
Posts: 3009
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: A Crittical look at ARM BASIC V.

Sun Dec 01, 2013 1:48 pm

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
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.
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.
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).
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.
Realy? Firstly i think you mean translate as a complete rewrite is unneeded just dumb translation.

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.
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.
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.
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.
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.
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.
I can not argue that. RISC OS is a greate OS and the ARM has become the most popular 32-bit CPU around.
ARM BASIC: For the love of Simplicity, Fast Interpreted BASIC, and Assembly Language.
Always KISS Keep It Simple Silly.

tufty
Posts: 1454
Joined: Sun Sep 11, 2011 2:32 pm

Re: A Crittical look at ARM BASIC V.

Sun Dec 01, 2013 2:03 pm

DavidS wrote:Yes my spelling is terrible, I use spell checking in everything that I can (unfortunately not available in the Web Browser)
You might want to consider using an operating system that has integrated spellchecking in edit boxes, then. There's a significant amount of choice out there.
DavidS wrote:I am aware that OS/2 was a joint project between MS and IBM. After the two had a falling out MS took there work in OS/2 and created from those ashes Windows NT. Thus my statement of NT evolving out of MS-OS/2, it did.
The OS/2 kernel was developed, from the ground up, by IBM. The GUI layer, Presentation Manager, which was delivered late (OS/2 1.3 if memory serves), was the main bit developed by Microsoft.

The NT kernel was developed, from the ground up, by Microsoft. The GUI layer GUI looked remarkably similar to OS/2 1.x's presentation manager, which, in turn, looked a lot like Windows 2.x. Unsurprisingly enough.

NT was a total shift from OS/2, in terms of code and concepts. If MS had "evolved" it from OS/2, they might have thrown away their craptastic UI and adopted something like OS/2 2.x's workplace shell. And I might even be using Windows today :)

Heater
Posts: 8111
Joined: Tue Jul 17, 2012 3:02 pm

Re: A Crittical look at ARM BASIC V.

Sun Dec 01, 2013 4:01 pm

DavidS,
Rewriting would mean changing something other than the opcodes.
One does not "just change" the opcodes, one changes the assembler instructions that produce those opcodes. I will state strongly that that is not a trivial task, it does not scale to large programs, the amount of work and scope for error becomes impossible. And hence we are back to what everyone knows: assembler programs are not portable.

I have a little story about that:

The Intel 8086 was specifically designed to be backward compatible with the 8080. The actual instruction encoding and assembler mnemonics were different but identical operations were provided.

Intel even provided a translation tool "Conv86" that would take 8080 assembly language and produce 8086 assembly language. Which could then be
assembled to run on your new 8086 machine.

I tried Conv86 out on a product I was involved with, it worked. Only problem was the resulting code was twice as big and ran less than half as fast on the 8086 as it did on the old 8085 hardware.

Why was that? Turned out that in order to get the meaning of that 8086 status flags exactly the same as the 8080 flags Conv86 put in a couple of extra instructions after many operations to tweak the flags into being correct. This had to be done so much the code became huge and slow.

No, problem, there was a switch for Conv86 that turned off this rigorous flag compatibility mode.

Great, now I had small fast code again. Only problem it did not work because the flags were set wrongly all over the place.

What to do? Well I could read all that ASM to look for the problems. Or I could run it under the in circuit emulator and check it. Well that was not going to happen, there was only one of me in the company to do that job and the code was huge. It was spread of four processors.

What happened? That code never made it to x86. I left the company. That control system withered and died. A waste of perhaps tens of man years of work.

So, if "translating" is so hard (impossible) in moving between such similar instruction sets it surely means a total rewrite for moving between different machines.

P.S. I have only seen versions of CP/M written in ASM. Such sources, as created by Digital Research are included in the Altair simulator here:
I believe however there were versions of CP/M's upper layers written in PL/M.

User avatar
DavidS
Posts: 3009
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: A Crittical look at ARM BASIC V.

Sun Dec 01, 2013 10:31 pm

@Heater:

Thank you. I do see the point when compatability accrossed multiple CPUs is a concern. I actually was doing some reasearch to point out a few things and learned that I was wrong about a few things.

I was going to point out Star Trek (the x86 clone of Macintosh System Software 7). Though it turns out that only the QuickDraw Toolbox, half of the Comm Toolbox, the low level disk IO, Color QuickDraw, and a few optimizations are written in Assembly in Macintosh System Software 7, and much of this is in ROM on 68K and PowerPC hardware, obviously in RAM on the x86 port that was never released. Most of Macintosh System software 7 is actually in C. Though most of the finder (the desktop application) is in Assembly.

I have a freind that has the entire source of Macintosh System Software 7.1.2 including a copy of the non numbered x86 sources, of cource the main source is for the 68K and PowerPC version.

And as to the example that you gave above, hand translation is almost always faster than automated methods of translation. This is due to the issues that you noted. Though if done by hand it takes surprisingly little time for most projects. The biggest berriers are interfacing to different OSes and HW, though this issue is still true for things written in an HLL, you still need to make the changes for the API and if any direct HW access is needed this is another area that things have to be changed even for a project written in an HLL. I have translated from i8080 to 8086 assembly quite a few times and it is very easy if done by hand, and amounts to dumb work. Now I would not want to translate between x86 and ARM, though this is due to the oddities of the x86 and not an inherent problem.

I enjoy Translating between ARM, PowerPC, MIPS, 680x0, 6502, 65816, PDP-11, and SPARC assembly as these are all so simple to go from any one of to any other of.

Though modern ideas do not even do that much in Assembly. There is no reason for this stuff to be in an HLL as it is mostly stuff that will change from one platform to the next.

==========================================================================

@Heater:
You actually have me looking at some of my old source that I had not touched in a long time because it was largely written in HLLs. This is source for an old project of mine to attempt to make a usable clone of the Mac OS. It is a small hobbiest project that I began working on back in the mid 1990s because I was afraid that one day Apple would abandon Mac OS. While they did Abandon Mac OS, and My OS would run a few applications (At least on the Macs that it would boot on) showing that I was on the correct track, I abandoned the project because it was largely written in HLLs (Mostly Pascal and C, with a bit of a homebrewed compiled BASIC [based on ARM BASIC V]).

Of cource I also wanted to be able to dissable the multifinder on an OS that is compatable with Macintosh System software 7.1.x. Single tasking is way under rated :) .

So maybe I will be looking at that project once again (see if I can get it to boot from Open Firmware on my G4 :) ). And maybe even see about getting it to boot on an ARM based computer known as the Raspberry Pi. This may be a good use of my time as it seems that more people are possitive about Mac OS Classic (or Real Mac OS) than are possitive about RISC OS. And as I want to see people using OSes that show many of the concepts that these OSes embody this could be a good thing to attempt (it already has a working 68020 emulator [instead of a 68LC040 emulator]), and actually runs more 68K apps than PowerPC apps despite being 100% PowerPC native.
ARM BASIC: For the love of Simplicity, Fast Interpreted BASIC, and Assembly Language.
Always KISS Keep It Simple Silly.

User avatar
DavidS
Posts: 3009
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: A Crittical look at ARM BASIC V.

Sun Dec 01, 2013 10:54 pm

Now if I understand what has been said about BASIC implementations and there pros and cons a good BASIC for more general application would be something like M$-QuickBasic for Macintosh with added support for color (like supported by FreeBASIC) and easier support for multi module programs (which is already supported by M$-QuickBasic for Macintosh). Is this about correct.

I say this as people seem to prefer that syntax, and M$-QuickBasic for Macintosh has simple means of handling GUI Components such as Windows, Buttons, Scroll Widgets, Etc and even Mouse Cursors.

I do admit that the support for Procedures that can be called by name with out a prefix, and the support for structure types is deffinitely a plus. Though I would also want pointers (Peek, PeekW, Poke, PokeW, etc do not cut it). Also explicit typing of veriables with out relying on a postfix is nice (though only supported in the last version of M$-QuickBasic for Macintosh).

If I have this all correct it will be time to code a simple self hosting recursive decent compiler targetting the ARMv6 and hosted on the ARM, targeting and hosted on for ARM Linux, RISC OS, ARM AROS, ARM DexOS (once that project is completed by DexOS). Though due to the complexity of Linux + X (or equilivelent) the support for that target would have to be minimal. I will include support for inline assembly (kind of a needed feature). I plan to begin this wednesday December the fourth of 2013 Anno Domni.

@Heater:
This will be much much more complicated a language than C, so you may wish to keep an eye if I succeed. I have kind of wanted to do this since the introduction of the Raspberry Pi :) .
ARM BASIC: For the love of Simplicity, Fast Interpreted BASIC, and Assembly Language.
Always KISS Keep It Simple Silly.

Heater
Posts: 8111
Joined: Tue Jul 17, 2012 3:02 pm

Re: A Crittical look at ARM BASIC V.

Sun Dec 01, 2013 11:52 pm

Interesting project idea. I will certainly keep an eye out for it.

RichardRussell
Posts: 140
Joined: Thu Jun 21, 2012 10:48 am

Re: A Critical look at ARM BASIC V.

Sat Aug 26, 2017 9:46 am

It's probably bad practice to resurrect a thread after nearly four years, but a lot has happened on the BBC BASIC scene since then and I thought it might be helpful to post an update for those who chance upon it, as I did.

Firstly I should say that I disagree with the assertion that 'ARM BASIC V' (that is specifically Sophie Wilson's implementation) is so distinct from other versions of BBC BASIC that it needs to be considered in isolation. In fact the differences between the various flavours of BBC BASIC (principally Sophie's ARM BASIC, Dave Daniels' Brandy and my versions) are very minor, at least in respect of their core features. Even what might be called 'quirks' of the language are in most cases faithfully reproduced.

One of the criticisms that was raised in the original thread was the non-availability of BBC BASIC for "PC's running Linux and Windows, Macs, Android phones and tablets...". In fact even then Brandy was available for Linux and Mac OS (and Brandy is 'BASIC V' in everything but name) and now there are editions of my BBC BASIC for SDL 2.0 for all those platforms, plus the Raspberry Pi running Raspbian. It will even run on an Amazon Fire TV Stick!

Another criticism was the lack of native support for Unicode strings. That has since been addressed to a degree in my versions, along with limited support for right-to-left printing languages like Hebrew and Arabic (albeit that these aren't really part of BASIC, but affect statements such as PRINT and VDU by virtue of the built-in emulation of some Acorn OS features). I have extended the WIDTH function to return the width (in graphics units, in the currently selected font) of a UTF-8 string.

So whatever your views on BBC BASIC, and it does seem to divide opinion, lack of availability and suitability for a wide range of 'modern' platforms is no longer a reason not to use it.

Richard.

Return to “Other languages”

Who is online

Users browsing this forum: Yahoo [Bot] and 10 guests