I also used the MSBASIC PDS 7.1 but never found mystelf giving anything up to C. Sure, some of the MS functions such as PRINT were dog slow but that was to maintain backward compatibility. One of my favorite add-on libraries was Quickpak by Crescent Software. These asm routines pretty much took care of any of the aforementioned slowness. Cool thing was that Crescent also provided 100% MASM source code and a assembly language tutorial that got me going right away. I was modifying their existing routines and creating my own in no time. I was obsessed with code size and performance but never had to consider another language.
I also used the MSBASIC PDS 7.1 but never found mystelf giving anything up to C.... PRINT were dog...asm routines pretty much took care of any of the aforementioned slowness...
This is very contradictory post. You did not give up anything, but you did give up speed, and for that you gave on on BASIC and used assembler!
I was obsessed with code size and performance but never had to consider another language.
The reason I refer to C as being a high level assembler is simple. The primary reason is to point out that C isn't truly a high level language but in fact a low level language. It is an abstraction to make it independent (for the most part) of the assembly/machine language of a given cpu or mpu and is capable of operations and functions not directly contained within the assembly/machine language of a given cpu or mpu. Which is why I refer to it as a high level assembly.
C is not considered a low level language. It is sometimes referred to as a high level language, but is more accurately a mid level language. Low level languages do not have hardware abstraction, and only work for the machine that they are designed for. For the most part, C is hardware-independent. However, as Roger pointed out it does not have garbage collection and other features that are attributes of high level languages.
This is very contradictory post. You did not give up anything, but you did give up speed, and for that you gave on on BASIC and used assembler!
Again, you did use another language, assembler.
Not contradictory at all. These were pre-compiled .objs that one declared and called (although source code was provided).
In this case, Print "Hello World" (used a BIOS call, I believe) simply became QPrint "Hello World" (wrote to video RAM).....hardly affected legibility.
Did you have to write assembler code to get your BASIC program to work with the performance required?
If no, OK, BASIC is the bees knees.
If yes, then, well, to say "I was obsessed with code size and performance but never had to consider another language." is indeed contradictory. You had to consider and use assembler.
... to point out that C isn't truly a high level language but in fact a low level language. ...
"High level language" means "higher than assembler". Above that is "natureal language" which is what many of us humans speak, and below that is microcode or machine language, which is used to program a CPU internally.
In between High level language and Natural language was supposed to be "fourth level language" which when Piccard asks the replicator for "Earl Grey, Hot", but this hasn't turned out right just yet.
In the world of computer programming they talk about language "generations" to some how categorize how "high level" they may be:
First generation languages have no assembler or compiler. Basically they are the instruction set of the machine. Your might enter your code by toggling switches on the front panel of the machine. Think PDP 11 or Altair.
Second generation programming languages (2GL) are assembly languages and are very machine-dependent.
Third generation languages (3GL) are much more machine independent and more programmer-friendly. These include C, C++, C#, Java, BASIC and Pascal and a billion others that have been developed since the first 3GL (Is that ALGOL or FORTRAN or COBOL?)
Fourth generation languages move us up in abstraction and deal with more complex data that bits and bytes. The definition seem a bit woolly but think data base manipulation and report generation.
Fifth generation languages seem to be based on the idea of specifying a problem and having the machine figure out the solution. One does not have to write algorithms any more. Woopee! A great idea that does not seem to have gotten very far.
Sorry for the confusion. All this talk of "These asm routines pretty much took care of any of the aforementioned slowness." made me think that writing assembler was an essential part of your projects.
Well, actually it was, only you did not write it people like Crescent Software did.
So, if it gets, the job done for you it is indeed the bees knees.
Still not attractive to me. Can you move that code to a Mac or Linux? Easily?
A decade or more ago, having seen the difficulties people and companies got into when they found their old code was no longer usable with the new computers or operating systems, I decided that all the code I write had to be portable.
How do you write portable C code when hardware is constantly becoming obsolete and even though it still works the OS or new system doesn't support I?
For example look at all the Parallax GPS and Bluetooth modules that have come and gone recently.
I've worked at places that are still using ancient computers and software because validating a new system is such a hassle. In one case just trying to get a Parallel Card to build a backup unit that had a Windows 98 driver was an exercise in futility but that software was written and validated on Windows 98. In another case an R&D tester died so were given the production backup unit and the sister company that builds these things kept dragging their feet on giving up replacements; They even said our units weren't supported because they were obsolete.
On another note, while BASIC may be a good starting language the concept of structured programming should be taught from day 1. I didn't learn that until I took PASCAL but now that I look at old BASIC program they irritate me because there are GOTOs all over the place.
A definite though, no matter the language, is documentation. I never thought much of it much when I was younger so many of the programs I wrote have little or no documentation unless it was required.
How do you write portable C code when hardware is constantly becoming obsolete and even though it still works the OS or new system doesn't support I?
For example look at all the Parallax GPS and Bluetooth modules that have come and gone recently.
You probably can't write portable code for low level hardware interfaces. However, many applications have lots of high level code that can be portable as long as you reimplement the low level code for the new platform. In fact, if your program doesn't do anything other than console and file I/O (not likely in micro controller applications), all of your code can be portable as long as you use a standard I/O library. In the extreme case, all of your code is heavily dependent on the hardware. In that case, there is no way to write portable code in any language.
On another note, while BASIC may be a good starting language the concept of structured programming should be taught from day 1. I didn't learn that until I took PASCAL but now that I look at old BASIC program they irritate me because there are GOTOs all over the place.
Given a large additional drawback of Basic, is the lack of a common vertical path, and pulling in two other threads...
P.S. Pascal is NOT dead. In fact I've even thought about writing a Pascal compiler for the Propeller. Any interest ?
Bean
With Lazarun running nicely on a Pi2, that idea of Bean's of a PropPascal sounds like a very good one.
It could have a library set chosen to make it easy to port existing Basic code, but the new code would also compile on any :Lazarus/FPC platform.
The Lazarus IDE already has full Pascal syntax support, and it can be use for Remote Debug, so there is a pathway to have users single-step their Prop-Pascal, on a Prop with Break/watch available, right down to a Pi2 level of host..
How do you write portable C code when hardware is constantly becoming obsolete and even though it still works the OS or new system doesn't support I?
Hmm...good question.
A particular project that I have been involved in, on and off, for twenty years now started life as an 8086 assembly language program. Of course written for some specific embedded system hardware that happened to use an 8086 as it's processor.
When I arrived on the scene the task was to reverse engineer that assembly language in to C so that it could be run on a different hardware with a Motorola 68000 based processor. I say "reverse engineer" because there was no documentation or specs as to how it should work, only the assembler source code.
(Does that sound familiar? That is how Roy Eltham has recently created OpenSpin in C++ from Chip's Spin compiler in x86 assembler!)
Some years later the company wanted to move that same code to a more advanced machine that was running the VxWorks operating system on a Power PC based micro controller. They called me.
More years later they wanted to move to Linux on the same architecture. They called me.
More years later it was time to move to ARM. They called me.
Oh, from the beginning my C version ran on Windows. So that it could be used in simulations of said device.
Point is there is a huge pile of code that is your application. And it rests on not so much code that interfaces to I/O ports and timers and whatever hardware.
And that is why C is a damn good idea if you want long lived, portable, software. That is why the Linux kernel is written in C and as you know runs on a huge variety of hardware.
I also used the MSBASIC PDS 7.1 but never found mystelf giving anything up to C. Sure, some of the MS functions such as PRINT were dog slow but that was to maintain backward compatibility. One of my favorite add-on libraries was Quickpak by Crescent Software. These asm routines pretty much took care of any of the aforementioned slowness. Cool thing was that Crescent also provided 100% MASM source code and a assembly language tutorial that got me going right away. I was modifying their existing routines and creating my own in no time. I was obsessed with code size and performance but never had to consider another language.
It's cool to meet someone else who use that development tool. During the years I used it I only ever met one person who had used it and he passed away shortly after I met him, so I never got to look at much of what he developed except a menu system for older DOS machines for a hospital. I used some of the more advanced commands such as PCOPY to screenshot the current display and restore it so I could do things like pop-up help screens. Fun times!
I'm sure there is a "p2c" translator somewhere....
I think there is for some definition of "p".
...Also, I imagine there is a Pascal front end to GCC.
Same again.
Why would anyone want to do this? Pascal is horrible. It has an ugly, verbose syntax. It's standards are all over the shop. It's ugly. It's verbose. It's obsolete. It begins with a "P" like those other horrid "P" languages like "Perl, PHP, Python, Prolog..."
OK, more seriously. Why Pascal? When it has the same features and offers nothing more than the common or garden C ?
Why would anyone want to do this? Pascal is horrible. It has an ugly, verbose syntax. It's standards are all over the shop. It's ugly. It's verbose. It's obsolete. It begins with a "P" like those other horrid "P" languages like "Perl, PHP, Python, Prolog..."
OK, more seriously. Why Pascal? When it has the same features and offers nothing more than the common or garden C ?
I never said I was an advocate of Pascal. I was just pointing out that it might not be difficult to get Pascal of some sort to run on the Propeller. You'd need a runtime library for the GCC version of Pascal but that might not be that hard to port.
re:Yup, and that can run on a PC or a Pi2, Great isn't it ?
In theory Lazarus will run anywhere where you can run Free Pascal and you have enough resources. Here is a list of Free Pascal targets (too long to post)
In theory Lazarus will run anywhere where you can run Free Pascal and you have enough resources. Here is a list of Free Pascal targets (too long to post)
The RaspPi 2 is probably important enough it should get its own line [ARM.Linux] is a bit anonymous.
I see mention of a JVB generator, I wonder how slow Lazarus IDE would end up under that ?
PASCAL on a Prop could be interesting. Check out the nice, clean, in-line syntax I found on Stack Exchange:
Yes, and there is also an established set of defines and tests, making it easy to create test suites on a PC/Pi2 host, and have the same source compile with PropPASCAL.
Symbols defined by the compiler.
FPC
VERv
VERv_r
VERv_r_p
OS
Predefined macros
Symbol Contains
FPC_VERSION The version number of the compiler.
FPC_RELEASE The release number of the compiler.
FPC_PATCH The patch number of the compiler.
{$ifdef fpc}
// This code on PC
var
y : longint;
{$else not fpc}
// This code on Prop
var
z : longint;
{$endif fpc}
{$if (fpc_version=0) and (fpc_release>9) and (fpc_patch>4)}
{$info At least this is version 0.9.5}
{$else}
{$fatal Problem with version check}
{$endif}
Compiled BASIC has had pointers since the mid 1970's, and you can get by with out them anyway (using peek/poke for data, and CALL for procedures), Compiled BASIC has supported inline assembly for a long time (at least since the late 1970's). Ok some variants do not have these extras, though most do.
MOST BASIC Compilers support:
+Structured Data Types.
+Explicit Declarations.
+Pointers (both data and procedure).
+Structured Procedures.
+Recursion.
+Fixed Length Strings.
+All the stuff we know BASIC for.
+Much much more.
I have seen more C compilers written in BASIC than BASIC compilers written in C. And any BASIC purest will say that you only write a BASIC Compiler in either BASIC (self hosting) or assembly language. This is a big problem that many have with FreeBASIC, while the compiler is written in BASIC the library functions (builtins) are mostly written in C (thus being a non pure implementation).
Used correctly BASIC can be just as fast as C, and in some ways more powerful. Most BASIC Compilers since about 1983 have supported fixed length strings with out garbage collection (the main slow down in BASIC).
The original BASIC supported multiprocessing (think threading), and many newer BASIC Compilers implement this functionality as well.
I often use C, just because it is expected. Though I prefer BASIC for a good compiled language.
There are at least two Operating Systems written completely in FreeBASIC. Further more there is an in progress project to implement a 100% Linux compatible kernel in FreeBASIC (sorry I do not have the links at this time).
It all comes down to perception. Many feel that BASIC is more of a toy language, usually do to the experience of the very limited BASIC interpreters on many 8-bit microcomputers.
As for portability there is more in common between most BASIC Compilers for most platforms than there is between the extensions of different C compilers (GCC is not everywhere). So most basic code is more portable than much C code (you would be surprised how many programs use extensions that are specific to one kind of C compiler [like the form of inline asm, or calling convention modifiers, etc]). It is usually a lot easier to port between incompatible BASIC implementations than between incompatible C compilers (where extensions are used).
MOST BASIC Compilers support:
+Structured Data Types.
+Explicit Declarations.
+Pointers (both data and procedure).
+Structured Procedures.
+Recursion.
+Fixed Length Strings.
+All the stuff we know BASIC for.
+Much much more.
Given that languages that support those things are not BASIC. But some new mutant languages inspired by ALGOL and it's children.
And given that those parent languages are actually well defined and standardized, why bother with the BASICs?
I have seen more C compilers written in BASIC than BASIC compilers written in C
Fascinating. Please supply references.
The original BASIC supported multiprocessing (think threading)...
Again, please supply references. I see no threading or multiprocessing mentioned in the original Dartmouth BASIC or many others that came since.
There are at least two Operating Systems written completely in FreeBASIC.
Perhaps, I found one. A crazy idea but why not?
Furthermore there is an in progress project to implement a 100% Linux compatible kernel in FreeBASIC
Do you mean this http://sourceforge.net/projects/linux-in-fb/?
Totally insane of course. Why make an old version of Linux in FB? We already have one in C!
Anyway, no files to view or download there.
So most basic code is more portable than much C code
Err, let's just say that experience causes me to disagree.
No one is yet living on Mars in year 2015, so I guess that's true...
You need a far more convincing point than that. Comparing all of the world's BASIC running systems (I'm not saying capable, but actually executing code) to what's running based on C (or just gcc) compiled code is like comparing Model Ts to Toyota Camrys. Sure, they were impressive in their time, were in almost every garage and barn, but Henry Ford would loved to have Toyota's sales.
Comments
Hi Chris,
I also used the MSBASIC PDS 7.1 but never found mystelf giving anything up to C. Sure, some of the MS functions such as PRINT were dog slow but that was to maintain backward compatibility. One of my favorite add-on libraries was Quickpak by Crescent Software. These asm routines pretty much took care of any of the aforementioned slowness. Cool thing was that Crescent also provided 100% MASM source code and a assembly language tutorial that got me going right away. I was modifying their existing routines and creating my own in no time. I was obsessed with code size and performance but never had to consider another language.
Not contradictory at all. These were pre-compiled .objs that one declared and called (although source code was provided).
In this case, Print "Hello World" (used a BIOS call, I believe) simply became QPrint "Hello World" (wrote to video RAM).....hardly affected legibility.
Did you have to write assembler code to get your BASIC program to work with the performance required?
If no, OK, BASIC is the bees knees.
If yes, then, well, to say "I was obsessed with code size and performance but never had to consider another language." is indeed contradictory. You had to consider and use assembler.
"High level language" means "higher than assembler". Above that is "natureal language" which is what many of us humans speak, and below that is microcode or machine language, which is used to program a CPU internally.
In between High level language and Natural language was supposed to be "fourth level language" which when Piccard asks the replicator for "Earl Grey, Hot", but this hasn't turned out right just yet.
Assembler and microcode are low level.
First generation languages have no assembler or compiler. Basically they are the instruction set of the machine. Your might enter your code by toggling switches on the front panel of the machine. Think PDP 11 or Altair.
Second generation programming languages (2GL) are assembly languages and are very machine-dependent.
Third generation languages (3GL) are much more machine independent and more programmer-friendly. These include C, C++, C#, Java, BASIC and Pascal and a billion others that have been developed since the first 3GL (Is that ALGOL or FORTRAN or COBOL?)
Fourth generation languages move us up in abstraction and deal with more complex data that bits and bytes. The definition seem a bit woolly but think data base manipulation and report generation.
Fifth generation languages seem to be based on the idea of specifying a problem and having the machine figure out the solution. One does not have to write algorithms any more. Woopee! A great idea that does not seem to have gotten very far.
Not at all. I didn't even possess MASM until later.
Quickpak.qlb was the "quick library" to be used with the QBX (Quickbasic) IDE
Quickpak.lib was the link library when a standalone .exe was required
I knew you'd get there...LOL!
Sorry for the confusion. All this talk of "These asm routines pretty much took care of any of the aforementioned slowness." made me think that writing assembler was an essential part of your projects.
Well, actually it was, only you did not write it people like Crescent Software did.
So, if it gets, the job done for you it is indeed the bees knees.
Still not attractive to me. Can you move that code to a Mac or Linux? Easily?
A decade or more ago, having seen the difficulties people and companies got into when they found their old code was no longer usable with the new computers or operating systems, I decided that all the code I write had to be portable.
How do you write portable C code when hardware is constantly becoming obsolete and even though it still works the OS or new system doesn't support I?
For example look at all the Parallax GPS and Bluetooth modules that have come and gone recently.
I've worked at places that are still using ancient computers and software because validating a new system is such a hassle. In one case just trying to get a Parallel Card to build a backup unit that had a Windows 98 driver was an exercise in futility but that software was written and validated on Windows 98. In another case an R&D tester died so were given the production backup unit and the sister company that builds these things kept dragging their feet on giving up replacements; They even said our units weren't supported because they were obsolete.
On another note, while BASIC may be a good starting language the concept of structured programming should be taught from day 1. I didn't learn that until I took PASCAL but now that I look at old BASIC program they irritate me because there are GOTOs all over the place.
A definite though, no matter the language, is documentation. I never thought much of it much when I was younger so many of the programs I wrote have little or no documentation unless it was required.
Given a large additional drawback of Basic, is the lack of a common vertical path, and pulling in two other threads...
http://forums.parallax.com/showthread.php/160718-Propeller-Chip-Raspberry-Pi-2-Interfacing-With-Free-Pascal-amp-Lazarus
With Lazarun running nicely on a Pi2, that idea of Bean's of a PropPascal sounds like a very good one.
It could have a library set chosen to make it easy to port existing Basic code, but the new code would also compile on any :Lazarus/FPC platform.
The Lazarus IDE already has full Pascal syntax support, and it can be use for Remote Debug, so there is a pathway to have users single-step their Prop-Pascal, on a Prop with Break/watch available, right down to a Pi2 level of host..
A particular project that I have been involved in, on and off, for twenty years now started life as an 8086 assembly language program. Of course written for some specific embedded system hardware that happened to use an 8086 as it's processor.
When I arrived on the scene the task was to reverse engineer that assembly language in to C so that it could be run on a different hardware with a Motorola 68000 based processor. I say "reverse engineer" because there was no documentation or specs as to how it should work, only the assembler source code.
(Does that sound familiar? That is how Roy Eltham has recently created OpenSpin in C++ from Chip's Spin compiler in x86 assembler!)
Some years later the company wanted to move that same code to a more advanced machine that was running the VxWorks operating system on a Power PC based micro controller. They called me.
More years later they wanted to move to Linux on the same architecture. They called me.
More years later it was time to move to ARM. They called me.
Oh, from the beginning my C version ran on Windows. So that it could be used in simulations of said device.
Point is there is a huge pile of code that is your application. And it rests on not so much code that interfaces to I/O ports and timers and whatever hardware.
And that is why C is a damn good idea if you want long lived, portable, software. That is why the Linux kernel is written in C and as you know runs on a huge variety of hardware.
So we have an editor (Lazarus) with Pascal syntax highlighting which can talk to a Pascal compiler and debugger on the target.
That is rather skipping the not so trivial detail of writing a Free Pascal code generator for the Propeller instruction set.
Anyone up for that?
Seems pointless given that we have C and C++ already.
It's cool to meet someone else who use that development tool. During the years I used it I only ever met one person who had used it and he passed away shortly after I met him, so I never got to look at much of what he developed except a menu system for older DOS machines for a hospital. I used some of the more advanced commands such as PCOPY to screenshot the current display and restore it so I could do things like pop-up help screens. Fun times!
Why would anyone want to do this? Pascal is horrible. It has an ugly, verbose syntax. It's standards are all over the shop. It's ugly. It's verbose. It's obsolete. It begins with a "P" like those other horrid "P" languages like "Perl, PHP, Python, Prolog..."
OK, more seriously. Why Pascal? When it has the same features and offers nothing more than the common or garden C ?
Yup, and that can run on a PC or a Pi2, Great isn't it ?
Did you miss my paste, of exactly that offer, from Bean, who wrote PropBASIC in Pascal ?
If it really was pointless, why did they bother to get Lazarus running on Pi2 ?
Given the vertical path choices, PropPascal looks a better choice for 'Basic' than a myriad of 'Basic's.
FreeBASIC would be my other choice, but the IDE & Debug effort there is more fragmented and there is not a fully working Pi2 solution.
re:Why would anyone want to do this? Pascal is horrible. It has an ugly, verbose syntax.
Actually, allot of Pascal code is just wrappers around C code to make it look pretty and presentable .
Re:GCC version of Pascal
Something like this? Maybe I'll start another thread
Welcome to GNU Pascal .
http://www.gnu-pascal.de/gpc/Welcome.html#Welcome
GNU Pascal
http://en.wikipedia.org/wiki/GNU_Pascal
re:Yup, and that can run on a PC or a Pi2, Great isn't it ?
In theory Lazarus will run anywhere where you can run Free Pascal and you have enough resources. Here is a list of Free Pascal targets (too long to post)
http://en.wikipedia.org/wiki/Free_Pascal#Targets
The RaspPi 2 is probably important enough it should get its own line [ARM.Linux] is a bit anonymous.
I see mention of a JVB generator, I wonder how slow Lazarus IDE would end up under that ?
function TestAsmFunction (variable1, variable2: longword): longword; register; asm MOV EAX, variable1 {actually unneccesary (= mov eax, eax)} PUSH EBX MOV EBX, variable2 {compiles to mov ebx, edx} AND EAX, EBX POP EBX end; {Return value is in EAX}Yes, and there is also an established set of defines and tests, making it easy to create test suites on a PC/Pi2 host, and have the same source compile with PropPASCAL.
http://www.math.uni-leipzig.de/pool/tuts/FreePascal/prog/node4.html
Symbols defined by the compiler.
FPC
VERv
VERv_r
VERv_r_p
OS
Predefined macros
Symbol Contains
FPC_VERSION The version number of the compiler.
FPC_RELEASE The release number of the compiler.
FPC_PATCH The patch number of the compiler.
{$ifdef fpc} // This code on PC var y : longint; {$else not fpc} // This code on Prop var z : longint; {$endif fpc} {$if (fpc_version=0) and (fpc_release>9) and (fpc_patch>4)} {$info At least this is version 0.9.5} {$else} {$fatal Problem with version check} {$endif}Compiled BASIC has had pointers since the mid 1970's, and you can get by with out them anyway (using peek/poke for data, and CALL for procedures), Compiled BASIC has supported inline assembly for a long time (at least since the late 1970's). Ok some variants do not have these extras, though most do.
MOST BASIC Compilers support:
+Structured Data Types.
+Explicit Declarations.
+Pointers (both data and procedure).
+Structured Procedures.
+Recursion.
+Fixed Length Strings.
+All the stuff we know BASIC for.
+Much much more.
I have seen more C compilers written in BASIC than BASIC compilers written in C. And any BASIC purest will say that you only write a BASIC Compiler in either BASIC (self hosting) or assembly language. This is a big problem that many have with FreeBASIC, while the compiler is written in BASIC the library functions (builtins) are mostly written in C (thus being a non pure implementation).
Used correctly BASIC can be just as fast as C, and in some ways more powerful. Most BASIC Compilers since about 1983 have supported fixed length strings with out garbage collection (the main slow down in BASIC).
The original BASIC supported multiprocessing (think threading), and many newer BASIC Compilers implement this functionality as well.
I often use C, just because it is expected. Though I prefer BASIC for a good compiled language.
There are at least two Operating Systems written completely in FreeBASIC. Further more there is an in progress project to implement a 100% Linux compatible kernel in FreeBASIC (sorry I do not have the links at this time).
It all comes down to perception. Many feel that BASIC is more of a toy language, usually do to the experience of the very limited BASIC interpreters on many 8-bit microcomputers.
As for portability there is more in common between most BASIC Compilers for most platforms than there is between the extensions of different C compilers (GCC is not everywhere). So most basic code is more portable than much C code (you would be surprised how many programs use extensions that are specific to one kind of C compiler [like the form of inline asm, or calling convention modifiers, etc]). It is usually a lot easier to port between incompatible BASIC implementations than between incompatible C compilers (where extensions are used).
What does that mean in layman's language?
And given that those parent languages are actually well defined and standardized, why bother with the BASICs? Fascinating. Please supply references. Again, please supply references. I see no threading or multiprocessing mentioned in the original Dartmouth BASIC or many others that came since. Perhaps, I found one. A crazy idea but why not? Do you mean this http://sourceforge.net/projects/linux-in-fb/?
Totally insane of course. Why make an old version of Linux in FB? We already have one in C!
Anyway, no files to view or download there. Err, let's just say that experience causes me to disagree.
Seriously though, I have no idea, I do not speak MBA.
No one is yet living on Mars in year 2015, so I guess that's true...
You need a far more convincing point than that. Comparing all of the world's BASIC running systems (I'm not saying capable, but actually executing code) to what's running based on C (or just gcc) compiled code is like comparing Model Ts to Toyota Camrys. Sure, they were impressive in their time, were in almost every garage and barn, but Henry Ford would loved to have Toyota's sales.
dgately