Basically it means being able to run your code on other systems, in a test wrapper.
Because everyone rolls their own Basic, there is no common vertical path, to run the same code on a larger host.
That is one of the reasons C manages to persevere.
A PropPASCAL that was based on Lazarus/FPC, could help change that, especially given the Pi2 can now run Lazarus.
Larger hosts could even get a simple PropEmulation library, and so allow even more of developers code to be tested before it is let loose on a Prop device.
Given the relatively poor debug support of a Prop, that sort of testing pathway is pretty important.
Lazarus is an IDE that is never going to run on a P1 or P2 so why are we talking about it? It's just a glorified editor after all.
I do agree it's convenient to run code on a host PC, check it out and debug it, before putting it on the target. That is why we often use C. I do the same with Pascal.
What "poor debug support of a Prop" ? We have 7 processes to watch what 1 process may be doing. Never had it so good!
Lazarus is an IDE that is never going to run on a P1 or P2 so why are we talking about it? It's just a glorified editor after all.
I'm not sure where this frequent diversion of 'never going to run on P1' comes from.
The IDEs I use are never going to run on the MCUs I target with them, and I never expect them to.
What an IDE buys you, is shiploads of code development ease - you get variable watch, you get syntax highlighting, you get declaration find, you get error message handling, you get breakpoints and single step....
There is a version of Lazarus that allows remote debug, which opens the potential to get all of the above features, on a Prop target (no, not totally hosted on the Prop, just the remote-debug stub needs to run on the Prop).
That is then just like the MCU development tools many other vendors provide for their devices.
As for "It's just a glorified editor after all" - hmm...
I have glorified editor's that I use, as well as Lazarus - why would I do that, if it really was just a glorified editor after all ??
- simple, the glorified editor lacksBreakpoints, Step and Watch features of Lazarus, but it can do some things Lazarus editor cannot.
re: GCC - No one is yet living on Mars in year 2015, so I guess that's true...
No, not that we know off. But I bet they can compile C code remotely on a Mars craft if they had to.
===================================================================================================================================
What is the Mars Curiosity Rover's software built in?
The code is based on that of MER (Spirit and Opportunity), which were based off of their first lander, MPF (Sojourner). It's 3.5 million lines of C (much of it autogenerated), running on a RA50 processor manufactured by BAE and the VxWorks Operating system. Over a million lines were hand coded.
The code is implemented as 150 separate modules, each performing a different function. Highly coupled modules are organized into Components that abstract the modules they contain, and "specify either a specific function, activity, or behavior." These components are futher organized into layers, and there are "no more than 10 top-level components."
Source: Keynote talk by Benjamin Cichy at 2010 Workshop on Spacecraft Flight Software (FSW-10), slides, audio, and video (starts with mission overview, architecture discussion at slide 80).
Take some code written in GCC that uses some of the GCC extensions frequently (that admittedly are copied by the Intel c compiler, Tiny C, and M$-VC), and attempt to compile it with a ANSI standard C compiler with out any extensions. You will see what I mean, C is everywhere, GCC is NOT.
And even with code that is ANSI C compliant:
What happens with unions that have varying size elements when you change to a platform that uses a different allignment requirement? Remember that "_packed" is NOT part of the standard, it is just an extension supported by SOME C Compilers.
Now what about byte ordering in unions, or other access of data in a way other than the original type? Some systems are little endian, some are big endian, some are mixed endian, that is a huge problem that most programmers do not pay attention to.
In porting C programs that do comply to the standards you have to think about all of these things. When you port applications that do not follow the standard there are even more pitfalls. And this stuff is so specific that it can NOT be automatically translated with any reliability.
With Compiled Structured BASIC:
The biggest differences are the Key Words chosen for the extensions. Though there is enough that is the same, and enough that is functionally the same that you can usually use an automated translation from one compiler to another, and get good results.
Take some code written in GCC that uses some of the GCC extensions frequently (that admittedly are copied by the Intel c compiler, Tiny C, and M$-VC), and attempt to compile it with a ANSI standard C compiler with out any extensions. You will see what I mean, C is everywhere, GCC is NOT.
And even with code that is ANSI C compliant:
What happens with unions that have varying size elements when you change to a platform that uses a different allignment requirement? Remember that "_packed" is NOT part of the standard, it is just an extension supported by SOME C Compilers.
Now what about byte ordering in unions, or other access of data in a way other than the original type? Some systems are little endian, some are big endian, some are mixed endian, that is a huge problem that most programmers do not pay attention to.
In porting C programs that do comply to the standards you have to think about all of these things. When you port applications that do not follow the standard there are even more pitfalls. And this stuff is so specific that it can NOT be automatically translated with any reliability.
With Compiled Structured BASIC:
The biggest differences are the Key Words chosen for the extensions. Though there is enough that is the same, and enough that is functionally the same that you can usually use an automated translation from one compiler to another, and get good results.
Does that explain my view a little better?
I would argue that there is more the same between two implementations of C than there is between two implementations of Basic. If you're willing to hand modify your code or use an automated translation tool, you'd have less work to do if the program was written in ANSI C than Basic. Of course, if you're the type of programmer who loves to litter their code with lots of non-ANSI extensions, the job will be more difficult. I always put all of that in a sort of "HAL layer" that is the only thing that needs porting. The endian and packing issues I'm sure apply as much to Basic as any other language. That is an incompatiblity between two pieces of hardware that has nothing to do with the programming language.
I do appreciate your view. Making code that is portable, cross-platform and long lived is a worthy goal.
My contention is that one can do that in C more easily than any dialect of BASIC or other language that is not standardized. As evidence I point out the billions of lines of C code out there that works on x86, ARM, 68000, PowerPC, MIPS, AVR, Propeller, etc etc etc. Not just across hardware architectures but across operating systems.
Yes, C is everywhere and GCC is not. That is why we talk about C not GCC. Why would one be using weird non-standard extensions to a language? (Yeah, I know the Linux kernel does. I forgive it that.)
What happens with unions that have varying size elements when you change to a platform that uses a different allignment requirement?
Unions are a sneaky way of getting a different view of the same memory space. Given that structure layout is implementation dependent, don't do that.
Now what about byte ordering in unions, or other access of data in a way other than the original type? Some systems are little endian, some are big endian, some are mixed endian, that is a huge problem that most programmers do not pay attention to.
We pay close attention to that. Normally endian issues are not a problem. How else do you think we can network machines of different word sizes, endianness, and so on.
I don't know of any language that will save you from taking any piece of memory, then treating it as a byte array, then having the problem that different machines store the bytes of their integers and so on in different orders in that memory.
Don't do that.
That automated translation to fix up BASIC dialects idea is cool. Though it sounds like another compilation step that is a pain.
I do appreciate your view. Making code that is portable, cross-platform and long lived is a worthy goal.
My contention is that one can do that in C more easily than any dialect of BASIC or other language that is not standardized. As evidence I point out the billions of lines of C code out there that works on x86, ARM, 68000, PowerPC, MIPS, AVR, Propeller, etc etc etc. Not just across hardware architectures but across operating systems.
Yes, C is everywhere and GCC is not. That is why we talk about C not GCC. Why would one be using weird non-standard extensions to a language? (Yeah, I know the Linux kernel does. I forgive it that.)
Unions are a sneaky way of getting a different view of the same memory space. Given that structure layout is implementation dependent, don't do that.
We pay close attention to that. Normally endian issues are not a problem. How else do you think we can network machines of different word sizes, endianness, and so on.
I don't know of any language that will save you from taking any piece of memory, then treating it as a byte array, then having the problem that different machines store the bytes of their integers and so on in different orders in that memory.
Don't do that.
That automated translation to fix up BASIC dialects idea is cool. Though it sounds like another compilation step that is a pain.
I must agree that if people programmed by the standard and paid attention to endians, then yes C would be easier to port. Though I have seen way to many cases where it is not so.
A very large percentage of the "Billions of lines" of code that you mention is not as portable as it appears. The use of GCC style extensions limits it to three or four of the more common compiler suits, though if you look at only operating systems targeted by GCC (or one of a couple that support the same proprietary extensions) your statement often holds.
One that is a common problem is the Boolean data type, that for a long time was in GCC and Intel CC, though was not part of the standard (I know that the 2011 standard added boolean data types).
As the newest C Standard that is universally agreed on is the original ANSI C standard (as outlined in the second edition K&R book), using elements of the newer standard can still be a problem. Unlike the original ANSI C standard, the newer updated standards have not been widely adopted as of yet. When the original ANSI C came out it was adopted quickly, this does not hold for the newer standards.
Not to mention that there are some C compilers that have trouble with the original K&R C (first edition) form.
Then there is still on occasion the need for the use of inline Assembly. This can be different between two compilers targeting the same CPU,as the standard does not specify how to implement the asm keyword.
Yes it is true that adding an automatic translator for porting compiled BASIC does add an extra step to the process. Though it is a lot better than attempting to port incompatible C, as automatic translation often does not work with C (no matter how well done), there are just to many commonly used tricks in the C programing language.
Yes it is true that adding an automatic translator for porting compiled BASIC does add an extra step to the process. Though it is a lot better than attempting to port incompatible C, as automatic translation often does not work with C (no matter how well done), there are just to many commonly used tricks in the C programing language.
I'm anxiously awaiting your automatic translator that will let me convert a QBasic program to pbasic. If you are even moderately careful, you can write C code that can be ported across a wide range of compilers and operating systems. I think think any amount of care will let you do that with Basic. Even sticking to ANSI Basic won't help because I doubt most modern Basic compilers implement that even as a subset of their full syntax. Anyway, let me know when your QBasic to pbasic translator is done.
I'm anxiously awaiting your automatic translator that will let me convert a QBasic program to pbasic. If you are even moderately careful, you can write C code that can be ported across a wide range of compilers and operating systems. I think think any amount of care will let you do that with Basic. Even sticking to ANSI Basic won't help because I doubt most modern Basic compilers implement that even as a subset of their full syntax. Anyway, let me know when your QBasic to pbasic translator is done.
Now propeller BASIC's are an exception to the rule LOL.
Though I do not know of a single BASIC Compiler that implements the entire ANSI standard (most leave out matrix operations, as well as a few other things).
A better standard would be MS 8KB BASIC (an interpreter, unfortunately), with subroutines in the form of QuickBASIC 2.0 and up. I say this as it is the form that almost all modern BASIC compilers take, as far as syntax and keywords. Yes the implementation of procedures is often worded differently, though usually with the same syntax. This goes from 6502 compilers on up to FreeBASIC. A couple examples are, ZBASIC, QuickBASIC, FreeBASIC, QB64, GSOFT-BASIC, Atari BASIC Compiler (more MS style than interpreted Atari BASIC), and many others.
Now the older compilers (pre 1977) were more like Dartmouth BASIC (which was a compiled BASIC), though that did not last.
As far as all the control structures in modern BASICs (WHILE, FOR, UNTIL, LOOP, CASE, etc), and the support of Pointers, and structured data types, well BASIC is based on ALGOL as well as fortran.
Now propeller BASIC's are an exception to the rule LOL.
Though I do not know of a single BASIC Compiler that implements the entire ANSI standard (most leave out matrix operations, as well as a few other things).
A better standard would be MS 8KB BASIC (an interpreter, unfortunately), with subroutines in the form of QuickBASIC 2.0 and up. I say this as it is the form that almost all modern BASIC compilers take, as far as syntax and keywords. Yes the implementation of procedures is often worded differently, though usually with the same syntax. This goes from 6502 compilers on up to FreeBASIC. A couple examples are, ZBASIC, QuickBASIC, FreeBASIC, QB64, GSOFT-BASIC, Atari BASIC Compiler (more MS style than interpreted Atari BASIC), and many others.
Now the older compilers (pre 1977) were more like Dartmouth BASIC (which was a compiled BASIC), though that did not last.
As far as all the control structures in modern BASICs (WHILE, FOR, UNTIL, LOOP, CASE, etc), and the support of Pointers, and structured data types, well BASIC is based on ALGOL as well as fortran.
You want a mess?
Try looking at the C compilers from before ANSI C, that is a mess.
Because much was undefined in the original K&R book, there was so much variation between different C compilers that it was even worse than what we can imagine now. Though thankfully most C compilers were small enough, and simple enough that hand porting them was a much simpler matter than it is today.
If we could have stuck with simple pipelining, and simple superscalar implementation of CPU's, optimization would be so much simpler. Even with the simple direct superscalar CPU's it would have been easy to reach the performance we have today (up to 16 operations per clock per core), and the CPU's would be a lot simpler (a good thing), and optimizing code for the CPU's would be a lot simpler.
Reality is that no language is truly portable, it is just degrees. Pascal with units is probably the closest to a truly portable language we have, though people would use implementation specific features even there (like the object pascal extensions that are implemented differently by different compilers).
You want a mess?
Try looking at the C compilers from before ANSI C, that is a mess.
Quite true. That's why they made the ANSI standard. Things have been better since then. However, even before the ANSI standard, I think were better than they ever have been with Basic. And what has the Basic community done to clean up their mess? Is there anything like the ANSI standard for C that has made basic more standard across implementations? I don't think so. It continues to be a mess.
Quite true. That's why they made the ANSI standard. Things have been better since then. However, even before the ANSI standard, I think were better than they ever have been with Basic. And what has the Basic community done to clean up their mess? Is there anything like the ANSI standard for C that has made basic more standard across implementations? I don't think so. It continues to be a mess.
While no one complies with the ANSI BASIC standard, there is a sub-set of BASIC that almost all modern BASIC implementations agree on, and a syntax that is agreed on.
All the operators are agreed on, as are most of the data types.
Put simply most modern BASIC compilers (post 1984) agree on the data types, how to declare variables, the data type postfixes for undeclared variables, how to implement functions and subroutines. Put simply you can generaly count on all operaters being identical, arrays and string handling being identical, and the following KeyWords (plus more, this is off the top of my head) being identical:
ABS(
PRINT
PRINT #
PRINT USING
INPUT
FOR TO NEXT
WHILE
WEND
SUB
FUNCTION
END
END SUB
END FUNCTION
EXIT
SYSTEM
VARPTR
PROCPTR
LONG
SHORT
BYTE
UNSIGNED
INPUT
INKEY
GETKEY
WHILE WEND
USR
RND
PEEK
POKE
MID$
LEFT$
RIGHT$
LEN
SIN
COS
SQR
VAL
STR
GOTO
ON GOTO
GOSUB
ON GOSUB
TYPE
END TYPE
LOOP UNTIL
AS
BYVAL
BYREF
AND
OR
XOR
NOT
And many more. In 1984 you could not count on anywhere near that level of consistency in C. And now C is better, though so is BASIC.
I'm not sure a list of keywords and function names proves anything. Just look for the collection of programs that worked across multiple implementations and I'll bet you'll find more C programs than Basic programs during the time when K&R was the standard and far more now that we have the ANSI standards. I myself wrote numerous compilers and interpreters as well as a database system and computer conferencing software that was portable across different implementations. And they were all easy to translate to ANSI C and still run on modern compilers.
In any case, I don't think you're wrong in choosing Basic for your project. PropBasic seems like a very nice Propeller Basic and I'm sure it will serve you well.
I'm not sure a list of keywords and function names proves anything. Just look for the collection of programs that worked across multiple implementations and I'll bet you'll find more C programs than Basic programs during the time when K&R was the standard and far more now that we have the ANSI standards. I myself wrote numerous compilers and interpreters as well as a database system and computer conferencing software that was portable across different implementations. And they were all easy to translate to ANSI C and still run on modern compilers.
That is definitely good.
Though I do not know how many thousands of "type in programs" were written in BASIC for interpreters that will compile with most BASIC Compilers on most platforms just by stripping off the line numbers (and some compilers do support line numbers), and using labels as branching targets.
I do agree that there is probably more C code even from that time that is portable. Though I believe that is only do to professional programmers preferring C over BASIC. Though at that time I think more software was written in assembly language's on microcomputers than any other language.
You actually got me to get out my First edition K&R book as well as my Second edition ANSI C K&R Book.
In any case, I don't think you're wrong in choosing Basic for your project. PropBasic seems like a very nice Propeller Basic and I'm sure it will serve you well.
Yes PropBASIC is a good language for the Propeller. It is well implemented, and it is target specific.
Yes PropBASIC is a good language for the Propeller. It is well implemented, and it is target specific.
And you appear to be making great strides (re: 3D printer) starting from scratch (the way that I would also approach it) compared to the apparent struggles of porting "portable" C.
A few years ago, I switched from the Windows platform to Android and, of course, I went with Basic4Android as opposed to Java. The differences between the PC Basic and B4A were something like a Monday-Tuesday problem....no big deal...and this is for a 12 axis+ CNC machine tool.
Net result is that I have Basic source that I can look at after a period of time and pretty much know exactly what it is supposed to do, thanks to the effectively self documenting nature of modern BASICs.
And you appear to be making great strides (re: 3D printer) starting from scratch (the way that I would also approach it) compared to the apparent struggles of porting "portable" C.
A few years ago, I switched from the Windows platform to Android and, of course, I went with Basic4Android as opposed to Java. The differences between the PC Basic and B4A were something like a Monday-Tuesday problem....no big deal...and this is for a 12 axis+ CNC machine tool.
Net result is that I have Basic source that I can look at after a period of time and pretty much know exactly what it is supposed to do, thanks to the effectively self documenting nature of modern BASICs.
I suppose it's probably true that most modern PC Basics are fairly similar largely due to everyone copying Microsoft. That certainly doesn't apply to pbasic though. What about other micro controller versions of Basic? Are they more compatible with the Microsoft defacto standard than pbasic is?
I'm not sure how Basic is any more or less self-documenting than any other block structured language but I guess if you're used to Basic syntax it is probably easier to read than C or Python or Javascript or whatever.
I suppose it's probably true that most modern PC Basics are fairly similar largely due to everyone copying Microsoft. That certainly doesn't apply to pbasic though. What about other micro controller versions of Basic? Are they more compatible with the Microsoft defacto standard than pbasic is?
I'm not sure how Basic is any more or less self-documenting than any other block structured language but I guess if you're used to Basic syntax it is probably easier to read than C or Python or Javascript or whatever.
I'm sure being familiar with the language syntax is one of the major factors, if not the major factor in preferring one language over another. When I was in university APL was my favorite language because I was familiar with the syntax, it was terse so it minimized typing (two finger typist), and it allowed me to do the kind of "what if" analysis we now do on spreadsheets. After reading the comments on APL here I guess I may have been part of a very small minority that liked APL. Perhaps even a minority of one.
I'm sure being familiar with the language syntax is one of the major factors, if not the major factor in preferring one language over another. When I was in university APL was my favorite language because I was familiar with the syntax, it was terse so it minimized typing (two finger typist), and it allowed me to do the kind of "what if" analysis we now do on spreadsheets. After reading the comments on APL here I guess I may have been part of a very small minority that liked APL. Perhaps even a minority of one.
I never had access to an implementation of APL that I could try but it always looked like an interesting language to me.
I'm sure being familiar with the language syntax is one of the major factors, if not the major factor in preferring one language over another.
I know very few folks that use a given language or tool based on the task at hand; most folks have one favorite tool and "make do" with it in all or most situations. At present, I only know of one guy that evaluations each new tool, and actively uses each when the situation is appropriate (and discards various tool when not appropriate for the application). This is my defition of software engineer, one that uses software tools as appropriate, and the given language is arbritary. Those of us that "make do" with a perfered tool may still get the job done, but we may be removing ourselves from the "software engineer" role.
The bigger problem with APL is that it is totally unintelligible unless you are seriously into mathematics.
How do you set a bit in an I/O port in APL?
I wasn't aware that it was intended to be used for that sort of application. I believe it was designed to be a tool for mathematicians. In that case, maybe it succeeded even though we non-mathematical programmers have a hard time understanding it.
I suppose it's probably true that most modern PC Basics are fairly similar largely due to everyone copying Microsoft. That certainly doesn't apply to pbasic though. What about other micro controller versions of Basic? Are they more compatible with the Microsoft defacto standard than pbasic is?
I'm not sure how Basic is any more or less self-documenting than any other block structured language but I guess if you're used to Basic syntax it is probably easier to read than C or Python or Javascript or whatever.
I suppose it's probably true that most modern PC Basics are fairly similar largely due to everyone copying Microsoft. That certainly doesn't apply to pbasic though. What about other micro controller versions of Basic? Are they more compatible with the Microsoft defacto standard than pbasic is?
I'm not sure how Basic is any more or less self-documenting than any other block structured language but I guess if you're used to Basic syntax it is probably easier to read than C or Python or Javascript or whatever.
Now self documenting I would question. I write just as much in comments for BASIC as I do for assembly on the same target.
Though yes it is do to the large amount of copying from M$ 8KB basic that we have so much in common in most micro-computer BASIC compilers. That and for structured BASIC the copying of declarations format, user data type format, and parametrized procedure format from MS-QBASIC.
Thouh as with any language when you get into graphics, sound, GUI, etc, etc, it becomes implementation specific. And those NON-BASIC languages that call themselves BASIC (eg newer versions of VB) and use strange OO stuff that does not fit, well they do not fit the rule in any way shape or forum (they have about as much in common with BASIC as BASIC does with BCPL).
Comments
Because everyone rolls their own Basic, there is no common vertical path, to run the same code on a larger host.
That is one of the reasons C manages to persevere.
A PropPASCAL that was based on Lazarus/FPC, could help change that, especially given the Pi2 can now run Lazarus.
Larger hosts could even get a simple PropEmulation library, and so allow even more of developers code to be tested before it is let loose on a Prop device.
Given the relatively poor debug support of a Prop, that sort of testing pathway is pretty important.
I don't get the idea.
Lazarus is an IDE that is never going to run on a P1 or P2 so why are we talking about it? It's just a glorified editor after all.
I do agree it's convenient to run code on a host PC, check it out and debug it, before putting it on the target. That is why we often use C. I do the same with Pascal.
What "poor debug support of a Prop" ? We have 7 processes to watch what 1 process may be doing. Never had it so good!
The IDEs I use are never going to run on the MCUs I target with them, and I never expect them to.
What an IDE buys you, is shiploads of code development ease - you get variable watch, you get syntax highlighting, you get declaration find, you get error message handling, you get breakpoints and single step....
There is a version of Lazarus that allows remote debug, which opens the potential to get all of the above features, on a Prop target (no, not totally hosted on the Prop, just the remote-debug stub needs to run on the Prop).
That is then just like the MCU development tools many other vendors provide for their devices.
As for "It's just a glorified editor after all" - hmm...
I have glorified editor's that I use, as well as Lazarus - why would I do that, if it really was just a glorified editor after all ??
- simple, the glorified editor lacks Breakpoints, Step and Watch features of Lazarus, but it can do some things Lazarus editor cannot.
re: GCC - No one is yet living on Mars in year 2015, so I guess that's true...
No, not that we know off. But I bet they can compile C code remotely on a Mars craft if they had to.
===================================================================================================================================
What is the Mars Curiosity Rover's software built in?
The code is based on that of MER (Spirit and Opportunity), which were based off of their first lander, MPF (Sojourner). It's 3.5 million lines of C (much of it autogenerated), running on a RA50 processor manufactured by BAE and the VxWorks Operating system. Over a million lines were hand coded.
The code is implemented as 150 separate modules, each performing a different function. Highly coupled modules are organized into Components that abstract the modules they contain, and "specify either a specific function, activity, or behavior." These components are futher organized into layers, and there are "no more than 10 top-level components."
Source: Keynote talk by Benjamin Cichy at 2010 Workshop on Spacecraft Flight Software (FSW-10), slides, audio, and video (starts with mission overview, architecture discussion at slide 80).
From Here:
http://programmers.stackexchange.com/questions/159637/what-is-the-mars-curiosity-rovers-software-built-in
==================================================================================
Wow >>> 3.5 million lines of C . Doesn't look like their's any Basic though LOL
A Component-based Framework for Space FSW
http://flightsoftware.jhuapl.edu/files/2010/FSW10_Veran.pdf
Oh my God, how did they ever get it to work? About the worst OS for embedded systems I have ever had the pleasure of working with.
And even with code that is ANSI C compliant:
What happens with unions that have varying size elements when you change to a platform that uses a different allignment requirement? Remember that "_packed" is NOT part of the standard, it is just an extension supported by SOME C Compilers.
Now what about byte ordering in unions, or other access of data in a way other than the original type? Some systems are little endian, some are big endian, some are mixed endian, that is a huge problem that most programmers do not pay attention to.
In porting C programs that do comply to the standards you have to think about all of these things. When you port applications that do not follow the standard there are even more pitfalls. And this stuff is so specific that it can NOT be automatically translated with any reliability.
With Compiled Structured BASIC:
The biggest differences are the Key Words chosen for the extensions. Though there is enough that is the same, and enough that is functionally the same that you can usually use an automated translation from one compiler to another, and get good results.
Does that explain my view a little better?
I do appreciate your view. Making code that is portable, cross-platform and long lived is a worthy goal.
My contention is that one can do that in C more easily than any dialect of BASIC or other language that is not standardized. As evidence I point out the billions of lines of C code out there that works on x86, ARM, 68000, PowerPC, MIPS, AVR, Propeller, etc etc etc. Not just across hardware architectures but across operating systems.
Yes, C is everywhere and GCC is not. That is why we talk about C not GCC. Why would one be using weird non-standard extensions to a language? (Yeah, I know the Linux kernel does. I forgive it that.) Unions are a sneaky way of getting a different view of the same memory space. Given that structure layout is implementation dependent, don't do that. We pay close attention to that. Normally endian issues are not a problem. How else do you think we can network machines of different word sizes, endianness, and so on.
I don't know of any language that will save you from taking any piece of memory, then treating it as a byte array, then having the problem that different machines store the bytes of their integers and so on in different orders in that memory.
Don't do that.
That automated translation to fix up BASIC dialects idea is cool. Though it sounds like another compilation step that is a pain.
A very large percentage of the "Billions of lines" of code that you mention is not as portable as it appears. The use of GCC style extensions limits it to three or four of the more common compiler suits, though if you look at only operating systems targeted by GCC (or one of a couple that support the same proprietary extensions) your statement often holds.
One that is a common problem is the Boolean data type, that for a long time was in GCC and Intel CC, though was not part of the standard (I know that the 2011 standard added boolean data types).
As the newest C Standard that is universally agreed on is the original ANSI C standard (as outlined in the second edition K&R book), using elements of the newer standard can still be a problem. Unlike the original ANSI C standard, the newer updated standards have not been widely adopted as of yet. When the original ANSI C came out it was adopted quickly, this does not hold for the newer standards.
Not to mention that there are some C compilers that have trouble with the original K&R C (first edition) form.
Then there is still on occasion the need for the use of inline Assembly. This can be different between two compilers targeting the same CPU,as the standard does not specify how to implement the asm keyword.
Yes it is true that adding an automatic translator for porting compiled BASIC does add an extra step to the process. Though it is a lot better than attempting to port incompatible C, as automatic translation often does not work with C (no matter how well done), there are just to many commonly used tricks in the C programing language.
Though I do not know of a single BASIC Compiler that implements the entire ANSI standard (most leave out matrix operations, as well as a few other things).
A better standard would be MS 8KB BASIC (an interpreter, unfortunately), with subroutines in the form of QuickBASIC 2.0 and up. I say this as it is the form that almost all modern BASIC compilers take, as far as syntax and keywords. Yes the implementation of procedures is often worded differently, though usually with the same syntax. This goes from 6502 compilers on up to FreeBASIC. A couple examples are, ZBASIC, QuickBASIC, FreeBASIC, QB64, GSOFT-BASIC, Atari BASIC Compiler (more MS style than interpreted Atari BASIC), and many others.
Now the older compilers (pre 1977) were more like Dartmouth BASIC (which was a compiled BASIC), though that did not last.
As far as all the control structures in modern BASICs (WHILE, FOR, UNTIL, LOOP, CASE, etc), and the support of Pointers, and structured data types, well BASIC is based on ALGOL as well as fortran.
Try looking at the C compilers from before ANSI C, that is a mess.
Because much was undefined in the original K&R book, there was so much variation between different C compilers that it was even worse than what we can imagine now. Though thankfully most C compilers were small enough, and simple enough that hand porting them was a much simpler matter than it is today.
If we could have stuck with simple pipelining, and simple superscalar implementation of CPU's, optimization would be so much simpler. Even with the simple direct superscalar CPU's it would have been easy to reach the performance we have today (up to 16 operations per clock per core), and the CPU's would be a lot simpler (a good thing), and optimizing code for the CPU's would be a lot simpler.
Reality is that no language is truly portable, it is just degrees. Pascal with units is probably the closest to a truly portable language we have, though people would use implementation specific features even there (like the object pascal extensions that are implemented differently by different compilers).
All the operators are agreed on, as are most of the data types.
Put simply most modern BASIC compilers (post 1984) agree on the data types, how to declare variables, the data type postfixes for undeclared variables, how to implement functions and subroutines. Put simply you can generaly count on all operaters being identical, arrays and string handling being identical, and the following KeyWords (plus more, this is off the top of my head) being identical:
ABS(
PRINT
PRINT #
PRINT USING
INPUT
FOR TO NEXT
WHILE
WEND
SUB
FUNCTION
END
END SUB
END FUNCTION
EXIT
SYSTEM
VARPTR
PROCPTR
LONG
SHORT
BYTE
UNSIGNED
INPUT
INKEY
GETKEY
WHILE WEND
USR
RND
PEEK
POKE
MID$
LEFT$
RIGHT$
LEN
SIN
COS
SQR
VAL
STR
GOTO
ON GOTO
GOSUB
ON GOSUB
TYPE
END TYPE
LOOP UNTIL
AS
BYVAL
BYREF
AND
OR
XOR
NOT
And many more. In 1984 you could not count on anywhere near that level of consistency in C. And now C is better, though so is BASIC.
In any case, I don't think you're wrong in choosing Basic for your project. PropBasic seems like a very nice Propeller Basic and I'm sure it will serve you well.
Though I do not know how many thousands of "type in programs" were written in BASIC for interpreters that will compile with most BASIC Compilers on most platforms just by stripping off the line numbers (and some compilers do support line numbers), and using labels as branching targets.
I do agree that there is probably more C code even from that time that is portable. Though I believe that is only do to professional programmers preferring C over BASIC. Though at that time I think more software was written in assembly language's on microcomputers than any other language.
You actually got me to get out my First edition K&R book as well as my Second edition ANSI C K&R Book. Yes PropBASIC is a good language for the Propeller. It is well implemented, and it is target specific.
And you appear to be making great strides (re: 3D printer) starting from scratch (the way that I would also approach it) compared to the apparent struggles of porting "portable" C.
A few years ago, I switched from the Windows platform to Android and, of course, I went with Basic4Android as opposed to Java. The differences between the PC Basic and B4A were something like a Monday-Tuesday problem....no big deal...and this is for a 12 axis+ CNC machine tool.
Net result is that I have Basic source that I can look at after a period of time and pretty much know exactly what it is supposed to do, thanks to the effectively self documenting nature of modern BASICs.
I'm not sure how Basic is any more or less self-documenting than any other block structured language but I guess if you're used to Basic syntax it is probably easier to read than C or Python or Javascript or whatever.
I'm sure being familiar with the language syntax is one of the major factors, if not the major factor in preferring one language over another. When I was in university APL was my favorite language because I was familiar with the syntax, it was terse so it minimized typing (two finger typist), and it allowed me to do the kind of "what if" analysis we now do on spreadsheets. After reading the comments on APL here I guess I may have been part of a very small minority that liked APL. Perhaps even a minority of one.
(~R∊R∘.
I know very few folks that use a given language or tool based on the task at hand; most folks have one favorite tool and "make do" with it in all or most situations. At present, I only know of one guy that evaluations each new tool, and actively uses each when the situation is appropriate (and discards various tool when not appropriate for the application). This is my defition of software engineer, one that uses software tools as appropriate, and the given language is arbritary. Those of us that "make do" with a perfered tool may still get the job done, but we may be removing ourselves from the "software engineer" role.
How do you set a bit in an I/O port in APL?
This is what I'm taking about!!!!
Though yes it is do to the large amount of copying from M$ 8KB basic that we have so much in common in most micro-computer BASIC compilers. That and for structured BASIC the copying of declarations format, user data type format, and parametrized procedure format from MS-QBASIC.
Thouh as with any language when you get into graphics, sound, GUI, etc, etc, it becomes implementation specific. And those NON-BASIC languages that call themselves BASIC (eg newer versions of VB) and use strange OO stuff that does not fit, well they do not fit the rule in any way shape or forum (they have about as much in common with BASIC as BASIC does with BCPL).
APL isn't designed for that.
Do you expect also expect a PLC (Programmable Logic Controller) to do 1,000,000 node FEA (Finite-Element-Analysis)?
You can't because it wasn't designed to do that.
Try duplicating what APL does with a single command and see how many lines of code it takes.
The right tool for the right job.
When you need to do mathematics you use APL.
When you need to play with I/O ports, you don't.
APL itself may have been written in C.