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.

Tue Nov 26, 2013 12:31 pm

As to the current debate on compiled vs interpreted lang:

Use a compiled language for high level apps if you do not like assembly. Use interpreted for small things that do not do much processing and not often (eg a calculator).

Only use assembly lang for an OS kernel and core OS Components.

And that is my view, I know that others will have differing views.
ARM BASIC: For the love of Simplicity, Fast Interpreted BASIC, and Assembly Language.
Always KISS Keep It Simple Silly.

Ravenous
Posts: 1956
Joined: Fri Feb 24, 2012 1:01 pm
Location: UK

Re: A Crittical look at ARM BASIC V.

Tue Nov 26, 2013 1:03 pm

DavidS wrote:Use a compiled language for high level apps if you do not like assembly. Use interpreted for small things that do not do much processing and not often (eg a calculator).
But isn't BASIC V interpreted, hence only suitable for small applications like calculators? (I don't know the answer to my own question, so if someone knows otherwise please correct me.)

Twinkletoes
Posts: 210
Joined: Fri May 25, 2012 9:44 pm

Re: A Crittical look at ARM BASIC V.

Tue Nov 26, 2013 2:22 pm

Personally I use a compiler whenever I can because it catches my sillies. That leaves me to get on with debugging my real design bugs, not my typos. When I refactor, a strongly typed language again catches most of my bugs in the compiler. I hate programming in Javascript for this reason, because I get slowed down looking for the missing semicolon rather than getting my thoughts arranged in code.

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

Re: A Crittical look at ARM BASIC V.

Tue Nov 26, 2013 2:25 pm

DavidS,
...a seasoned programmer should have a good enough familiarity with the language that they use to write a usable recursive decent compiler for that language with enough of it complete to compile itself in under a week...
I don't believe you. Are you saying you can write a C compiler (or similarly complex HLL compiler) in a week? If so I have a challenge for you: Can you write a C compiler for the Propeller MCU from Parallax Inc by next Wednesday? The target architecture is described here http://www.parallax.com/sites/default/f ... v1.2_0.pdf

I have known hundreds of very competent programmers only a few of which had any clues about compiler writing and I doubt any of those could pull it off in a week.
Use a compiled language for high level apps if you do not like assembly. Use interpreted for small things that do not do much processing and not often (eg a
calculator).

Only use assembly lang for an OS kernel and core OS Components.
It would be a very different world if we abided by your rules:

1) Most worlds web sites would not exist, a huge proportion of them are powered by interpreted languages, Python, PHP, Ruby, JavaScript. I would even include
Java in that list.

2) We would have no Linux. Or if we did, being written in assembler it would be stuck on Intel x86.

I'm kind of glad we don't live in that world.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 18196
Joined: Sat Jul 30, 2011 7:41 pm

Re: A Crittical look at ARM BASIC V.

Tue Nov 26, 2013 3:07 pm

I find myself in agreement with heater (Yes, I know - there's a first time for everything). I look at compilers and think - how the hell do they do that. And yet I am a generally competent programmer (YMMV), who doesn't have the faintest idea how to write a compiler (I did write a bit of one using YACC and LEX at University about 28 years ago - I do remember it wasn't complicated).

I do have an article I keep meaning to read that explains they are not as complicated as people think, but until i do read, they are as difficult as I think
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Please direct all questions to the forum, I do not do support via PM.

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

Re: A Crittical look at ARM BASIC V.

Tue Nov 26, 2013 3:35 pm

jamesh,
I find myself in agreement with heater
What?!

Let's go down the pub an celebrate. We can have an argument over which beer is best:)

I had no idea about writing a compiler until I read "Let's Build a Compiler" by Jack Crenshaw.http://compilers.iecc.com/crenshaw/ Highly recommended to anyone who is curious about such things. It describes how to build a compiler for a language with "if", "for", "while", "case", functions, procedures etc. You are encouraged to design your own language though.

I even managed to implement a compiler that contained most of the ideas there and generated code for the x86 and then later the Propeller micro controller. Very inefficient code but it worked which was enough for me. My compiler was written in C rather than Jack's Pascal examples. There are probably ideas in there can be applied to lot's of other programming problems. I liked it because it did not cheat by using tools like lex or yacc, it's all coded by hand.

Anyway, I'm sure even a compiler for that kind of simple language takes more than a week.

Real compilers for real languages are far bigger and more complex.

ZXDunny
Posts: 80
Joined: Sun Jul 08, 2012 7:57 pm

Re: A Critical look at BBC BASIC V.

Wed Nov 27, 2013 1:15 am

DavidS wrote: As to justifying itself, do you (or anyone) know of a purely interpreted (no jit stuff) BASIC implementation with at least the feature set of BBC BASIC V that is as fast as the BBC BASIC V interpreter? I certainly do not.
I have a copy of RiscOS running on the OpenPandora. I also have the usual Angstrom Linux running on it. BBC BASIC V runs quite well, but in like-for-like tests, PandaBAS is faster. PandaBAS is purely interpreted, has no inline assembler and no integer types, just floats and strings. PandaBAS does have procedures, functions, the ability to include libraries (which are written in PandaBAS), advanced graphics and sound capabilities. Sound is provided by an external library though. The interpreter constructs p-code on the fly, and is an interactive interpreter, just like BASIC V.

The thing is, the PandaBAS has much more advanced capabilities built-in - as tokens. There's space for a full longword of tokens, too - so a very intensive task like, say, rotating and scaling a 256 colour graphic is as simple as

10 WINDOW PUT GRAPHIC id,window,x,y ROTATE r SCALE s

Which is to say that anything that I found that wasn't fast enough to do in pure interpreted BASIC was then generalised and added as a command. So while PandaBAS doesn't have the complete feature set of BASIC V, it's purely interpreted and very much faster than BASIC V, depending on what you want to do. In BASIC V, if the user wants to perform some sort of function he or she must delve into assembler. With PandaBAS, they just have to email me to request the functionality :)

Although PandaBAS is available for x86 and ARM (OpenPandora and RasPI versions are around) I'd say that it has a similar sized audience to that of BASIC V.

I'm not bothered by that, and neither should you be.

D.

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.

Wed Nov 27, 2013 3:12 am

Ravenous wrote:
DavidS wrote:Use a compiled language for high level apps if you do not like assembly. Use interpreted for small things that do not do much processing and not often (eg a calculator).
But isn't BASIC V interpreted, hence only suitable for small applications like calculators? (I don't know the answer to my own question, so if someone knows otherwise please correct me.)
Both interpreted and compiled. The current standard compiler is ABC, though there have been better ones in the past.
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.

Wed Nov 27, 2013 3:27 am

Heater wrote: I don't believe you. Are you saying you can write a C compiler (or similarly complex HLL compiler) in a week? If so I have a challenge for you: Can you write a C compiler for the Propeller MCU from Parallax Inc by next Wednesday? The target architecture is described here http://www.parallax.com/sites/default/f ... v1.2_0.pdf

I have known hundreds of very competent programmers only a few of which had any clues about compiler writing and I doubt any of those could pull it off in a week.
Now the prop is a bit more complicated a target. I do not have the time at the moment with the american holiday this week.

And you seem to forget that I specified a simple non-optimizing Recursive decent compiler with out any of the standard libs. All of the other compiler writers for the P8X32A are attempting to provide verious optimizations (like the extend memory modules) and a form of standard lib as well as a number of extensions for graphics and such. All of that takes more time.

And I did say that I knew that not all would agree with my views.

After the holiday and finishing another project I will take your chalenge, though beings that it will not start by your deadline it will not meet your deadline.

ALSO: C is one of the simplest languages around. It is the libs that get a bit complex.
It would be a very different world if we abided by your rules:

1) Most worlds web sites would not exist, a huge proportion of them are powered by interpreted languages, Python, PHP, Ruby, JavaScript. I would even include
Java in that list.
I must disagree with that.

We would use binaries for server side dynamic content hosting instead of these scripts. And well applied Java Script is only used for the small things that interpreters are appropriate for. There are many web servers that only accept the use of binaries for this purpose, and they tend to be better applied.

Java is of limited use in my view, actualy I would prefer if it never existed.

2) We would have no Linux. Or if we did, being written in assembler it would be stuck on Intel x86.

I'm kind of glad we don't live in that world.
Ok I guess that Unix (like MINIX) is good in C, though this is by design and is one of very few exceptions to the Assembly language OS rules. I was speeking more in regards to day to day usage OSes which Unix has never fit (and yes I include Linux, BSD, and MINIX in Unix).

A day to day use OS is supposed to be non portable as far as the level that you are thinking.
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.

Wed Nov 27, 2013 3:33 am

jamesh wrote:I find myself in agreement with heater (Yes, I know - there's a first time for everything). I look at compilers and think - how the hell do they do that. And yet I am a generally competent programmer (YMMV), who doesn't have the faintest idea how to write a compiler (I did write a bit of one using YACC and LEX at University about 28 years ago - I do remember it wasn't complicated).

I do have an article I keep meaning to read that explains they are not as complicated as people think, but until i do read, they are as difficult as I think
If you are attempting to use one of the lexer packages (like YACC + LEX) it would be rather difficult. It is recursive decent compilers that I speak of. These are very simple to construct for most languages.

The reason that the simple compilers like this are not more common is that it is not so easy to implement optimizations in this model, though it is quite effective at compiling standard procedural and OO languages. It is a method that even applies to C++ before the bad idea of Templates was added.

There are a number of tutorials around the net if you are not familiar with how a recursive decent compiler works. The quickest to study that I have found to point people towards is CUCU:
http://zserge.com/blog/cucu-part1.html
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 Critical look at BBC BASIC V.

Wed Nov 27, 2013 3:39 am

ZXDunny wrote:
DavidS wrote: As to justifying itself, do you (or anyone) know of a purely interpreted (no jit stuff) BASIC implementation with at least the feature set of BBC BASIC V that is as fast as the BBC BASIC V interpreter? I certainly do not.
I have a copy of RiscOS running on the OpenPandora. I also have the usual Angstrom Linux running on it. BBC BASIC V runs quite well, but in like-for-like tests, PandaBAS is faster. PandaBAS is purely interpreted, has no inline assembler and no integer types, just floats and strings. PandaBAS does have procedures, functions, the ability to include libraries (which are written in PandaBAS), advanced graphics and sound capabilities. Sound is provided by an external library though. The interpreter constructs p-code on the fly, and is an interactive interpreter, just like BASIC V.

The thing is, the PandaBAS has much more advanced capabilities built-in - as tokens. There's space for a full longword of tokens, too - so a very intensive task like, say, rotating and scaling a 256 colour graphic is as simple as

10 WINDOW PUT GRAPHIC id,window,x,y ROTATE r SCALE s

Which is to say that anything that I found that wasn't fast enough to do in pure interpreted BASIC was then generalised and added as a command. So while PandaBAS doesn't have the complete feature set of BASIC V, it's purely interpreted and very much faster than BASIC V, depending on what you want to do. In BASIC V, if the user wants to perform some sort of function he or she must delve into assembler. With PandaBAS, they just have to email me to request the functionality :)

Although PandaBAS is available for x86 and ARM (OpenPandora and RasPI versions are around) I'd say that it has a similar sized audience to that of BASIC V.

I'm not bothered by that, and neither should you be.

D.
Ok you have my attention. And as to be equal in testing I must assume that your tests work purly on integer values and in BBC BASIC V use the integer variable type correct?

This is needed for equal testing as 99% of all of the programs use only integer math and BBC BASIC V does not use HW floating point (this is no loss as most programs have no use of Floating point).

Though you definitely got my attention and curiosity. How are you able to verify that it is a pure interpreter (or did you look at the source to verify the lack of any runtime code gen)?
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.

Wed Nov 27, 2013 3:41 am

@ZXDummy:

Also you show the use of a to high level command, does this PandaBAS allow the use of lower level system calls through the SWI interface (used in the ARM Linux kernel as well as RISC OS)?
ARM BASIC: For the love of Simplicity, Fast Interpreted BASIC, and Assembly Language.
Always KISS Keep It Simple Silly.

ZXDunny
Posts: 80
Joined: Sun Jul 08, 2012 7:57 pm

Re: A Critical look at BBC BASIC V.

Wed Nov 27, 2013 9:15 am

DavidS wrote: Ok you have my attention. And as to be equal in testing I must assume that your tests work purly on integer values and in BBC BASIC V use the integer variable type correct?
You didn't read my post. PandaBAS has no integer support at all - it uses floats for all numerical operations. ARM's hardware floating point on the OpenPandora is dire - VFPv3 is very slow.
Though you definitely got my attention and curiosity. How are you able to verify that it is a pure interpreter (or did you look at the source to verify the lack of any runtime code gen)?
I wrote it.
Also you show the use of a to high level command, does this PandaBAS allow the use of lower level system calls through the SWI interface (used in the ARM Linux kernel as well as RISC OS)?
PandaBAS is the OS. The interpreter is built-in.

D.

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

Re: A Crittical look at ARM BASIC V.

Wed Nov 27, 2013 10:19 am

DavidS,
...you seem to forget that I specified a simple non-optimizing Recursive decent compiler with out any of the standard libs
No, I don't forget. I don't care about any standard libs, only the language. Also I said nothing about external memory support. Straight forward native Propeller code would do fine.
...the prop is a bit more complicated a target
Actually it's a very simple target if you are sticking to pure native code (more on that later). It has a very simple regular instruction set with most of the instructions a compiler would like to emit. ADD, SUB, MOV, AND, OR, XOR, CMP, CALL, RET, various condition jumps, shifts, etc. There are many other strange Prop specific instructions that can be handled with intrinsics or in-line assembler if need be.

The hard part, is that such native code is restricted to the 2KBytes of the Props processor (called a COG). And there is no stack support, CALL stores it's return address in a field of the corresponding RET instruction. As such I would allow the compiler to not support recursive functions. Recursive functions are not much used in MCU programs anyway.

Such native Propeller code was what the prop-gcc guys implemented first as executing code from the 32KB RAM space requires a run time kernel. Mind you if you borrowed the run time kernel from propgcc it would probably be easier to target that.

2K of COG is only 512 instructions which sounds useless but it was enough for me to write a bit banging full duplex UART with GCC. It also holds the inner loops of my integer only FFT for significant speed up.

Oh did I say, we can forget floating point support.

Actually David, you should not take my challenge so seriously, even if you can do it in a week it's still a week of your time which you could no doubt use gainfully in some other way. Besides the last thing the world needs is Propeller C compiler written in ARM assembler that only runs on RISC OS:)

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 18196
Joined: Sat Jul 30, 2011 7:41 pm

Re: A Crittical look at ARM BASIC V.

Wed Nov 27, 2013 10:33 am

Heater wrote:jamesh,
I find myself in agreement with heater
What?!

Let's go down the pub an celebrate. We can have an argument over which beer is best:)

I had no idea about writing a compiler until I read "Let's Build a Compiler" by Jack Crenshaw.http://compilers.iecc.com/crenshaw/ Highly recommended to anyone who is curious about such things. It describes how to build a compiler for a language with "if", "for", "while", "case", functions, procedures etc. You are encouraged to design your own language though.

I even managed to implement a compiler that contained most of the ideas there and generated code for the x86 and then later the Propeller micro controller. Very inefficient code but it worked which was enough for me. My compiler was written in C rather than Jack's Pascal examples. There are probably ideas in there can be applied to lot's of other programming problems. I liked it because it did not cheat by using tools like lex or yacc, it's all coded by hand.

Anyway, I'm sure even a compiler for that kind of simple language takes more than a week.

Real compilers for real languages are far bigger and more complex.
#
Thanks for the link.

And it's Summer Lightning btw. Although I am also partial to a good IPA or EPA.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Please direct all questions to the forum, I do not do support via PM.

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

Re: A Crittical look at ARM BASIC V.

Wed Nov 27, 2013 10:38 am

DavidS,

My observation about the growth of the WEB and scripting languages is that when we first got the WEB and web servers we also had C , C++ and other compiled
languages. The explosive growth took off with the arrival of things like PHP, Python etc. Not to mention Java then Ruby and so on. Clearly if the WEB relied on people writing C that explosion would have been thousands of times smaller and slower. We would not be where we are today.
There are many web servers that only accept the use of binaries for this purpose, and they tend to be better applied.
There are? Can you link me to one?
Java is of limited use in my view, actualy I would prefer if it never existed
I would not say Java has limited use, people use it for kinds of things. However I do agree, it has no reason to exist.
I was speeking more in regards to day to day usage OSes which Unix has never fit...Linux, BSD...
This is a bizarre statement. Unix, in the form of Linux is a perfectly fine day to day usage operating system. Linux is probably the single most used operating system kernel in the world thanks to Android. Now there is Chrome OS and such coming along.
A day to day use OS is supposed to be non portable as far as the level that you are thinking
WTF? Says who? In old days "day to day" operating systems were written in assembler and non-portable. They are all now dead and buried, along with the companies that made them mostly. Think CP/M, MSDOS, yes even RISC OS. Prior to that probably things like VAX VMS and whatever IBM big iron used.

Even Microsoft can build Windows for ARM or other architectures when they want to. I'm sure they would be cursing themselves if they had written the NT kernel in
x86 assembler!

Ravenous
Posts: 1956
Joined: Fri Feb 24, 2012 1:01 pm
Location: UK

Re: A Crittical look at ARM BASIC V.

Wed Nov 27, 2013 10:39 am

Oh don't start 'em off about beer. I can imagine no end of transatlantic arguments about the recommended serving temperature, before we even get to the beer itself.

Besides anything that takes more than a week to make isn't worth using :lol:

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.

Sat Nov 30, 2013 3:11 am

Heater wrote:DavidS,

My observation about the growth of the WEB and scripting languages is that when we first got the WEB and web servers we also had C , C++ and other compiled
languages. The explosive growth took off with the arrival of things like PHP, Python etc. Not to mention Java then Ruby and so on. Clearly if the WEB relied on people writing C that explosion would have been thousands of times smaller and slower. We would not be where we are today.
Now that is debatable. I would say that the learning curve is smaller with compiled languages and equally capable. I do think that it would have created some unique extensions for compiled languages that target the generation of HTML.
There are many web servers that only accept the use of binaries for this purpose, and they tend to be better applied.
There are? Can you link me to one?
As I only use those that I write for specific purposes I must point to one that inspired me a long time ago (JAFFA):
http://www.rowan.sensation.net.au/programs.html

Java is of limited use in my view, actualy I would prefer if it never existed
I would not say Java has limited use, people use it for kinds of things. However I do agree, it has no reason to exist.
I was speeking more in regards to day to day usage OSes which Unix has never fit...Linux, BSD...
This is a bizarre statement. Unix, in the form of Linux is a perfectly fine day to day usage operating system. Linux is probably the single most used operating system kernel in the world thanks to Android. Now there is Chrome OS and such coming along.
I guess it depends on how you look at it. I would say that a day to day use OS does not waste resources for things that are not needed for the day to day use, and even most end user distros of Linux are guilty of having many unneeded extras for what the user is doing.

I am not speaking of how the OS is abused though rather its best use. Realy do not feel like diving into every little detail on that one.
A day to day use OS is supposed to be non portable as far as the level that you are thinking
WTF? Says who? In old days "day to day" operating systems were written in assembler and non-portable. They are all now dead and buried, along with the companies that made them mostly. Think CP/M, MSDOS, yes even RISC OS. Prior to that probably things like VAX VMS and whatever IBM big iron used.
WTF?????
Since when doe an assembler based OS have to be non-portable? It has been many times proven that an assembler written OS can be portable. The first example that stands out is actually a layer running above a much simpler OS and that is the 8-Bit MS-BASIC implementations that were ported from the 8080 to the 6502 then to the 6809, and eventually the same BASIC to the 8086. And there have been many others (though my mind is not engaging at the moment).


Just because many abuse Linux and NT does not make them true day to day OSes, if they were there would not be so many troubles resulting from there use in day to day application (and thus outside there ideal usage).

There is a reason that Windows was never portable (though I like neither it is to bad that Windows was replaced by NT. Windows (3.11 through 98SE) was a better series of Operating systems for day to day usage).

Then there was Macintosh System Software / Mac OS. Though this system is now dead (unfortunately), it was a true day to day usage OS that implemented all of the features that were needed with out adding anything to get in the way. You see for a single user OS (one for day to day use in other words) that can only be used from the local terminal there is no need for 99.9% of the extra crap that is inherent to unixens. All of its life much of Mac OS was written in 68K assembler, with latter versions using a lot of PowerPC assembler to speed things up on the PowerPC CPU. This even holds true after the introduction of Macintosh System Software 7, which had much rewritten in C (though mostly those things previously written in Pascal). And there is nothing stopping Mac OS from being used today it has everything that is needed (other than user support) of a modern system even more so than RISC OS, or Haiku OS. Though we all know that Apple abandoned Mac OS for Darwin long ago and the ex-mac users seem not interested in maintaining the great OS that once was :( .

Point is do not attempt to make one OS do everything, design a day to day OS for its intended purpose.
Even Microsoft can build Windows for ARM or other architectures when they want to. I'm sure they would be cursing themselves if they had written the NT kernel in
x86 assembler!
Ok show me one windows version that has been built for anything other than x86 (and I mean Windows, NOT NT, NOT CE, as these are different OSes altogether). As Windows requires MS/PC/DR-DOS I will be quite surprised.

And NT is not Windows (NT is called Windows NT 3.x/4.x, Windows 2000/2003/2008, Windows XP/Vista/7/8 though it is still seperate from windows). Windows is MS-Windows 1.0x, 2.xx, 3.xx, 95, 95 OSR2, 95OSR2.5, 98, 98SE, ME. Windows is a dead DOS Shell program.
ARM BASIC: For the love of Simplicity, Fast Interpreted BASIC, and Assembly Language.
Always KISS Keep It Simple Silly.

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

Re: A Crittical look at ARM BASIC V.

Sat Nov 30, 2013 9:00 am

DavidS,

If that Jaffa WWW server for DOS does what it advertises on link you gave then it uses CGI. Therefore it does not insist on binaries.
Since when doe an assembler based OS have to be non-portable?
By definition. If you write a program in assembler for the native instruction set of some machine then clearly it will not run on some other architecture. You have to rewrite the whole thing or provide an emulation of on the new target.
It has been many times proven that an assembler written OS can be portable.
No it has not. Unless you have an example.
The first example that stands out is actually a layer running above a much simpler OS and that is the 8-Bit MS-BASIC
The original MS BASICS were very small programs (4KBytes) clearly the were rewritten for the 6502 and so on. I do not call rewriting a program for a new architecture "porting". I call that rewriting.

The Mac transitions from 68000 to PowerPC is a fine example of what I'm talking about. Apple did not "port" to the PowerPC they provided emulation to run the old non-portable Mac binaries. That worked because the PPC was so much faster. They did it again when moving from PowerPC to Intel.
Ok show me one windows version that has been built for anything other than x86 (and I mean Windows, NOT NT, NOT CE, as these are different OSes altogether). As Windows requires MS/PC/DR-DOS I will be quite surprised....And NT is not Windows
You do not get to define what "Windows" is. Microsoft does.

True enough old Windows on top of DOS was never ported to anything. It was x86 specific. It relied on MSDOS which was written in assembler hence demonstrating by point that assembler code is not portable.

Later Windows, from Windows NT up, were written in C/C++ and have been ported to other architectures: IA-32, MIPS, Dec Alpha, PowerPC, Itanium, AMD64 and ARM.

I rest my case.

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

Re: A Crittical look at ARM BASIC V.

Sat Nov 30, 2013 3:31 pm

jamesh wrote:I look at compilers and think - how the hell do they do that. And yet I am a generally competent programmer (YMMV), who doesn't have the faintest idea how to write a compiler (I did write a bit of one using YACC and LEX at University about 28 years ago - I do remember it wasn't complicated).

I do have an article I keep meaning to read that explains they are not as complicated as people think, but until i do read, they are as difficult as I think
Heater wrote:I had no idea about writing a compiler until I read "Let's Build a Compiler" by Jack Crenshaw.http://compilers.iecc.com/crenshaw/ Highly recommended to anyone who is curious about such things. It describes how to build a compiler for a language with "if", "for", "while", "case", functions, procedures etc. You are encouraged to design your own language though.
Crenshaw's an excellent resource. Abdulaziz Ghuloum's work is also worth a read, and then there's Krishnamurthi's "Programming Languages : Interpretation and Application" (PLAI) and Friedman & Wand's "Essentials of Programming Languages". Should be enough to start scratching the surface :)

Once you start thinking of compilers as merely a sequence of source to source transforms, it starts looking remarkably simple. Not simple enough that you'll get a good one up in a week, but relatively simple nonetheless.

If you're not writing a compiler in and for a language that makes its parse tree available, however, you're gonna have to start dealing with parsing/ lexing, and that gets all sorts of painful /real/ fast.

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.

Sat Nov 30, 2013 10:18 pm

Heater wrote: The original MS BASICS were very small programs (4KBytes) clearly the were rewritten for the 6502 and so on. I do not call rewriting a program for a new architecture "porting". I call that rewriting.
I would still call it porting as it works the same internaly. Yes the opcodes changed though the algorithms stayed the same. I do admit that it was a very small task to port compared to more modern OSes.
The Mac transitions from 68000 to PowerPC is a fine example of what I'm talking about. Apple did not "port" to the PowerPC they provided emulation to run the old non-portable Mac binaries. That worked because the PPC was so much faster. They did it again when moving from PowerPC to Intel.
Whil much of the Macintosh System Software / Mac OS ran only in emulation at first much was rewritten in PPC assembly (most notably QuickDraw). Yes some components were redone in C that were originaly 68K-Asm (a decision that I still dissagree with). Though as to the 68K emulation this is needed as most apps were only available as compiled/assembled binaries even if the OS is 100% PowerPC native. The same issue arises with Windows NT (evolved MS-OS/2 not related to Windows) as most applications have been distributed as binary only, so it does not matter if it is ported to another CPU as many of the original authors are no longer around, and much software has been abandoned by the publishers with the source lost to time.

Many Applications that were written for the 68K Macintosh will never be made PowerPC native because the source has been lost to history, so we need the 68K emuklation layer that is part of the Mac OS Nano Kernel for all PowerPC Mac OS implementations. I still hold out hope that Apple will eventualy bring back the real Mac OS though I know that my hopes are in vein.

You see my preference in Operating Systems is RISC OS first followed closely by Mac OS (Pre-Darwin), then Atari TOS (without MiNT [There are other multitaskers]), followed by Amiga OS.
You do not get to define what "Windows" is. Microsoft does.
I can not argue that. And Microsoft made it clear that Windows NT and Windows are two seperate product lines.

Windows NT is a weard evolution of MS-OS/2, Windows is Microsofts GUI product line for the average user.
True enough old Windows on top of DOS was never ported to anything. It was x86 specific. It relied on MSDOS which was written in assembler hence demonstrating by point that assembler code is not portable.
And how many Windows applications that were provided by now extinct Software Houses can be ported? That I would think would be important to porting an Operating System. There are still many applications that are from now dead software houses simply because an equilivelent in usability and feature set has never been created to replace them, many of these require now old OSes (mostly Macintosh System Software and Atari TOS), and these applications will never be ported to another CPU.
Later Windows, from Windows NT up, were written in C/C++ and have been ported to other architectures: IA-32, MIPS, Dec Alpha, PowerPC, Itanium, AMD64 and ARM.
OS/2 was always designed to be portable. As you said listen to Microsoft on what is windows, and they were quite clear that Windows NT (eg late MS-OS/2) is a seperate product from Windows.
I rest my case.
And I thank you for making my case for me.

Though your views are strange for one that likes Propeller Assempbly.

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


The different views on compilers I have always found interesting. Compilers are fairly simple and it would take some time to implement a GOOD compiler for a given language (exctepting BF), though it is an easy thing to implement a simple recursive decent compiler that produces working code in less than a week, or even in a week end if it is for a language that does not support structured data types.

The only rule to keeping it easy is to always code your own lexer and do your own parsing (regardless of the method of parsing that you use). The verious "Parsing" languages and high level lexers make the task more difficult than it should be.


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

I think that this topic has went many directions. I think it is clear that people are more interested in doing things the hard way than thinking about what is actually going on. So I feel that this topic is done.
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.

Sat Nov 30, 2013 11:40 pm

@Heater:
Thank you. You got me thinking about Macintosh and I now have my Macintosh PowerPC G4 733MHz QuickSilver hooked up running Mac OS 9.2.2.

If I could find the project that is attempting to clone the Real versions of Mac OS, it comes to mind that this could be an ideal OS for the Raspberry Pi, and the 68LC040 Emualtor should be just as fast if rewritten for the ARM CPU giving a large library of pre-existing software.

Unfortunately I forget the name of the project to clone the Mac OS (Classic that is) and can not find it anywhere (i know it is out there).
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 7:34 am

DavidS wrote:OS/2 was always designed to be portable. As you said listen to Microsoft on what is windows, and they were quite clear that Windows NT (eg late MS-OS/2) is a seperate product from Windows.
David, your grasp of computing history is worse than your spelling.

OS/2 was a joint project launched by IBM and MS. MS stiffed IBM, pushing instead the internal development of Windows 95, and subsequently, *separately*, developed the NT kernel (team headed by Dave Cutler, ex VMS guy).

OS/2 was not designed to be portable. NT, the kernel at least, was.

As for "being a separate product", yes, Windows NT was a separate product from Windows 98. Or Windows 95. Or (shudder) Windows ME. Or (again shudder) Windows 8. Or Windows XP Embedded. On the other hand, it's the *same* product, as they all implement the Win32 API, meaning Windows software from the older platforms can run on the newer ones (perhaps modulo a recompile here or there).

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

Re: A Crittical look at ARM BASIC V.

Sun Dec 01, 2013 11:26 am

"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

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.

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.

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.

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.

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.

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:26 pm

tufty wrote:
DavidS wrote:OS/2 was always designed to be portable. As you said listen to Microsoft on what is windows, and they were quite clear that Windows NT (eg late MS-OS/2) is a seperate product from Windows.
David, your grasp of computing history is worse than your spelling.

OS/2 was a joint project launched by IBM and MS. MS stiffed IBM, pushing instead the internal development of Windows 95, and subsequently, *separately*, developed the NT kernel (team headed by Dave Cutler, ex VMS guy).
Yes my spelling is terrible, I use spell checking in everything that I can (unfortunately not available in the Web Browser),

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.
OS/2 was not designed to be portable. NT, the kernel at least, was.
Ok my error. I had thought that this was because IBM later did port OS/2 to other platforms (eg PowerPC) even if OS/2 never became popular outside of the x86 PC/AT compatable.
As for "being a separate product", yes, Windows NT was a separate product from Windows 98. Or Windows 95. Or (shudder) Windows ME. Or (again shudder) Windows 8. Or Windows XP Embedded. On the other hand, it's the *same* product, as they all implement the Win32 API, meaning Windows software from the older platforms can run on the newer ones (perhaps modulo a recompile here or there).
Windows 4.x (95, 98, ME) had a Win32 layer to support some Windows NT applications. They were largely based on Windows 3.x (16-bit), Windows NT had a native win32 API. So your argument is paramount to saying that Linux with WINE is the same thing as Windows, I do not think so.

Yes the Win32 API was intended to be somewhat similar to the Win16 API.
ARM BASIC: For the love of Simplicity, Fast Interpreted BASIC, and Assembly Language.
Always KISS Keep It Simple Silly.

Return to “Other languages”

Who is online

Users browsing this forum: No registered users and 8 guests