It's great to see some enthusiasm for a simple language that compiles line-by-line to PASM, that's lean and fast and is easy to learn.
Better late than never!
Isn't this the crux of the dilemma, that while it compiles PASM it is limited to 496 instructions, that's it. To be really useful in this same manner the P1 would have to be a P2, which it ain't, so perhaps PropBasic will come into it's own as many other languages and tools will when P2 is out.
Not really, Peter. PropBasic supports LMM so you can have a large main program and small tasks for things that need to run concurrently. For that matter, if a task needs more than 496 instructions it can run LMM as well (I've not needed to do that).
Here's an example. I don't have a CS background, nor am I an engineer, and I'm really hesitant to post code that I've written or a hardware design but I think someone needs to show that PropBasic can be a serious tool. I don't hold this up as an example of how to do anything except include WAY too many comments (intended for me and my lousy memory), and if I started over I'd probably do some things differently. That said, it's a fairly significant application in PropBasic, in fact the most complicated thing I've ever coded. It's a GPS-based video timing overlay that reads GPS NMEA time info, phase-locks a Silicon Labs Si504 oscillator (now EOL, sadly) to the PPS and generates an internal timebase from which the overlay info is derived. I modified Bean's video driver to be an OSD, using sync from a LMH1980 sync separator. This has a LMM main program and the other seven cogs run cog code. I'm not one to post videos and such or I'd post a demo showing that it really does work. And I wouldn't have had a prayer of coding this in PASM.
If you critique the hardware or the code, please remember I'm just a tinkerer and there may well be blunders. If it weren't for this discussion, I'd never have posted this. The take home message is that not being an engineer or programmer, I could still take on a (for me) very challenging project and get it working. Don't even ask how long it took
[edit] typo
I've now uploaded a bit of video so you can see what it does.
The video is directly captured with no audio, and the background is sync plus black level so all you see is the output from the overlay generator. The little demo shows it waiting for the PPS pulse interval to settle down (despite claims, they are frequently erratic for several seconds and the code has to see 10 consecutive seconds of stable output), checking the NMEA time for a monotonic count sequence (again, 10 seconds without a hiccup) and then locking to the PPS. The format has the time in HH:MM:SS plus fraction for both fields of the frame. At the lower right is a running field count. The generator was intended mostly for time-stamping video shot through a telescope (asteroid occultations, primarily) so it would normally be over a starfield. The display format is mostly for historical reasons. An overlay generator that was commercially available for several years originated that display format and I used it just so anyone who had to do timing analysis of one of my video records would easily recognize the format.
Once the thing locks to the PPS, I run it through the various adjustments: brightness, vertical position of the time display (to accommodate monitors that chop off the end of the field, or to allow the display to be at the top), display width, and centering. A raw NMEA sentence display is next, followed by a screen that shows the loop behavior with time error on the top and frequency offset below. The offset isn't an error, per se, since I tweak the oscillator to keep the Prop clock locked to the PPS. It bounces around a bit, partly because the Garmin GPS PPS signal is only stable at about the 100 ns level, and partly because the Si504 oscillator's minimum adjustment interval is 2.4 Hz (0.149 Hz in the datasheet, but multiplied by the Prop's clock PLL) which is too coarse for a really accurate adjustment. Since the LSD of the time stamp is 100 us, an error of tens of nanoseconds is perfectly adequate.
The last screen looks pretty bizarre. It's an attempt at giving a user a way to confirm that the timestamps are accurate (assuming the GPS is accurate). The flash every second is actually the PPS signal itself, injected onto the video, and the idea is that the user would single-step through a video record until reaching a field where the leading edge (top) of the PPS "block" is on the graticule. The graticule provides an easy way to tell which scanline the leading edge falls on, then using the horizontal line time of 63.5 us for NTSC or 64.0 us for PAL, the time between the current field's vertical sync (corresponding to the time stamp) and the leading edge of the next PPS can be calculated. If that time interval is subtracted from 1 (since the PPS is for the next second), the result should be equal to the time stamp for that field, +/- 1 least significant digit.
Any adjustment that's made is written to EEPROM so it survives a power cycle.
I hope this is an adequate demo & explanation without further hijacking Bean's thread.
I must be really missing the point then when I hear PASM along with lean and fast and then .... LMM! ?
Did you note that the video driver was written in PropBasic?
[edit] I obviously don't have your background, Peter, but that's partly the point of this discussion. No one would doubt that someone with sufficient background can get good performance out of the Prop. But what about the rest of us? Is a EE the price of admission?
But "pretty fast" is not cog speed, it's limited by the hub fetch loop and latency. But then it's not lean either.
I'm multitasking here but I'm simply saying something that Bean is very well aware of, that the nice fast cog code is limited.
The reason we have languages and tools is so that we can build apps. So the measure of the approach is how well apps can be implemented on the limited resources of the P1.
In the application I uploaded, there's one LMM cog and seven cogs running cog code within their cog memory space. So first PropBasic is too limited because it can only have 496 instructions, and then it's too slow because one out of eight cogs is running LMM. You're a hard man to satisfy, Peter!
Compared to how Peter works in Forth, it is limited.
"fast" can run all over the place. LMM code is not COG code, but it's not SPIN code either, thus "pretty fast" and arguably, fast enough for a whole lot of things.
As for lean, another day. There are more axis to that than are currently being allowed for in this discussion, and it's a PBASIC thread anyway.
P2?
Yeah, this can shine on that one. When it's closer to being real silicon, good times!
Of course it looks nothing like BASIC. I'm not sure whey PropBASIC has "BASIC" in the name. Except of course I guess it is using line breaks as a major part of it's syntax, not free form like C'ish languages.
As I said, I kind of like the idea of a single operation per expression. It's something I considered when I first thought about writing a compiler years ago. Before I got lead astray by the concept of recursive descent parsers, operator precedence, etc. See how easily allowed Jones to comment every step of the way.
I like the idea that "if" cannot do assignments. This is clean. No side effects.
I like that it can produce LMM as well as raw PASM. Peter will say that is not "lean". True enough all those 32 bit instructions are big and some kind of byte code thing would help. But it is "lean" conceptually and pretty speedy.
I like that "if" always needs "endif". Unless it's all on one line. (as far as I can tell that is so)
I presume this cannot support recursive function calls. No worries, MCU programmers hardly ever use them, if they even know how. Recursive is for academics and CS students who want to show off their Ackerman function coding skills Not supporting recursive makes for efficiency.
Of course there are some things I would have done differently:
I would use LET for introducing variables:
LET LONG x = 10
Named parameters to functions with the usual round brackets would be nice.
Maybe I have been a little harsh on PropBASIC, their just might be more to it than I thought; a couple of recommendations.
The other day I wanted to do a Windows installation, man was it a pain to find the binaries, again. Since this thread might turn out to be an active one, stays up front for awhile, could you place the latest usable binaries in the first post along with the docs. Or maybe some other way of getting to the binaries and docs could be made; it seems like DropBox is being used quite a bit.
The documentation, looking at the actual size of the pdf file, I think it is what, 100 pages or so. Maybe if you got rid of a lot of the white space, the size, could be reduced too maybe 20 pages or less. I would also recommend maybe some more examples, it seems like "COGSTART taskname{,var}", could be made more explanatory.
Not sure what the progress with PropBASIC and Propeller IDE is, maybe a rehash of the different methods of working with PropBASIC could be in order. That could probably be the first thing that somebody looks at in your doc file.
No one would doubt that someone with sufficient background can get good performance out of the Prop. But what about the rest of us? Is a EE the price of admission?
Hold on there. EE is the real world of device physics. It is only when you cross over into CS that you find all of the man-made rules (compilers, language syntax, interpreters, etc.). While some enjoy dwelling in that space, I find it a necessary evil.
In my book EE is all about Maxwell's equations. It's nice to know some physics beyond that but most of electronics is an abstraction over those details. One does not need to to know the quantum mechanics of a transistor to design with them.
CS is all about computers and computing. That is the theoretical investigation of what they can do and how fast they can do it. Algorithms and algorithm analysis. Actual hardware or actual programming language are somewhat irrelevant to all that.
All that practical stuff about languages, syntax, parsers, code generators is Software Engineering.
Most of us know little of any of those things. We just hack what we can, learn what we have to, until it works.
Of course there is a lot of overlap in all of these things.
And especially when messing with micro-controllers, driven by software, which are connected to electronics, which are connected to mechanical things, all of which we are trying to make for ourselves there can be a lot to assimilate.
Hence the need to keep it simple. For those who don't have huge amounts of time to invest into learning details they don't need to know to get things to work. Hence things like BASIC, Spin, Python, Javascript....
I'm not one to post videos and such or I'd post a demo showing that it really does work.
An image of a screenshot is ok, pictures do not have to be animated.
I'll see if I can do something.
Guys, I didn't mean to hijack the thread, only to offer an example of a significant (to me, anyway) application to counter the impression that PropBasic is just for little demos or toy programs. I suppose I should've also pointed out that those eight files are all one "app", main is LMM in cog 0 and it loads the other seven task files into the other cogs. Also note that my coding style makes it all look a lot more verbose and cluttered than it needs to.
Looks like all the loops we need are covered. Is there a CASE?
I was about to say there is no FOR, this really isn't BASIC. But then I found it
FOR X = 0 to 10 STEP 2
...
NEXT
Phew!
No CASE. You can get some of the functionality by using ON-GOTO or ON-GOSUB with an explicit list of values to compare against. A significant limitation is that with ON-GOSUB you can't pass parameters to a subroutine.
Hold on there. EE is the real world of device physics. It is only when you cross over into CS that you find all of the man-made rules (compilers, language syntax, interpreters, etc.). While some enjoy dwelling in that space, I find it a necessary evil.
Didn't mean to be that specific. I was referring to having at least an undergraduate degree in engineering, computer science, etc., IOW having a lot of the background training that Heater mentioned, as opposed to those of us who might read a book or just dive in. For example, after many years of tacking chips together, I can generally figure out how to get chip A to work with microcontroller B and get enough out of a datasheet to write a driver and get it working, but if there are subtle issues that require extensive test equipment, lots of background, or tricky code I may be in over my head. You can probably tell from my code that I take a fairly simplistic approach to things.
I should also acknowledge that there is "lean and fast" for folks like Peter and there is "lean and fast" for folks like me and I'm well aware they aren't the same thing. If I can cram the needed functionality into a cog, I couldn't care less about optimization and/or elegance. If it works, I'm good.
In technical college, many decades ago, we were doing some electronic circuit experiments. Our lecturer told us that if you gave a choke and a transformer to most EE graduates they would not be able to tell you which was which. How we laughed.
Some years later, having graduated in Physics, it seemed he was right. The many of the EEs I knew could not tell one end of a soldering iron from another.
A few years ago, I stumbled across a YouTube video where some EE lab manager in a US university was lamenting the same problem.
Now of course it's good that someone knows all that intense theoretical stuff, but it use to be that kids arrived at uni having been tinkering with electronics since they were nippers. That's why they came to study EE.
Similarly, in the CS world world. The 1980's youngsters arrived at Uni for their CS studies and already knew how to program in BASIC and assembler, having been brought up on C64s and Sinclair Spectrums. They came enthusiastically to learn more. Now a days they arrive at Uni knowing nothing and it takes a year to get them up to speed. All they have is a vague hope of a well paying job.
So, we, happy hackers, I believe they call it "Makers" now a days can, in some respects, be far ahead of the EE and CS types.
Note: All the above is a terrible generalization but you get the idea.
It is really interesting to watch the GDC Classic Postmortem series. All these guys talk about their early experiences. Assembly language, constraints (and that 8 bit era was full of them), and how that forced them to reason about the task.
This is part of why I'm a fan of simple languages and when they offer up assembly language in a similar, simple way. All the good, higher level stuff, portability, etc... get ignored for a time in favor of basic literacy and fluency.
The result is something a person can reason about and get things to work.
Once it does work, they may get hooked, and once there, will progress as their skill exceeds the simple, enabling environment.
On that note, SPIN+PASM, being one unified, simple thing that also offered reuse in a similar, simple way, is brilliant.
Anyway, having a nice BASIC makes sense for those reasons. People may just want to do stuff, and if they can do it, they are happy. Some will want more. Others may just do more stuff. All good.
It's an odd thing, and I wonder if it still happens today, but back in 1973 when I did a CS course, old English "A" level at age 16. We were introduced to programming with BASIC and within a month or so assembler as well. We were expected to know both for projects and final examinations.
Maybe I'm weird but I soon found that quite a few things I wanted to do were much easier in assembler than BASIC!
Remember this is all being done via a teletype and acoustic modem to some remote mainframe.
It was a CS course. Only one third of it was anything to do with actual programming or computers, the rest of it was numerical analysis and statistics. After all, you need to have a reason for all this programming stuff right?
Which makes me wonder where Obama's 4 billion for point and click programming in schools is going to go. Nothing to do with CS. That would buy about 40 million Propellers or Raspi systems for school kids where they could get down to the real stuff if they want to. But that's another worm can.
You aren't weird. Some things are easier in assembly language. I and my peers had similar experiences.
This does depend on the assembly language some. Different CPUS have different sweet spots.
Also, it's fast. Often, it's not really necessary to optimize for peak performance. Just get it done. An old 8 bit BASIC is really slow. But, if it has inline, it can do a ton more. If it can be compiled, that's even better. People don't have to know much to make things happen, and it's the making of the happening that enables the making of the understanding.
(Yes, I wrote that for your entertainment Heater...)
And when it comes to special hardware features, being able to write assembly, quick, lean, fast can make them more accessible and useful as one can more fully exploit them. In this microcontroller / embedded space, I see that as just as relevant today as it was a requirement to make 8 bit computers do anything interesting at all.
When it's packaged up into a keyword or library, that may not all be true, and it's more frequently true for "off label" uses. (A good example is the standard video library I owe Brett. To fully exploit a P1 takes assembly language or a skilled programmer using compiled COG code. But, some general cases make sense.)
The cost is portability.
And that, right there seems to be the fault line related to inline and assembly in general. If doing that gets loaded up with other features to improve on portability, the quick, lean, accessibility goes out the window. But, it's still fast and able to directly exploit hardware.
If it is super easy, it's generally not portable, but then again it's super easy, so it's not as big of a deal to rewrite or modify code to fit too.
And, doing it is discouraged overall. As it should be, but for those cases where it can make good sense. Again, in this space, it often can.
...it's the making of the happening that enables the making of the understanding.
(Yes, I wrote that for your entertainment Heater...)
I love it. Being an old guy now I have this weird urge to make some happening that leads to the making of the understanding among the youngsters I meet. I'm not very good at this.
On one recent occasion a couple of nice young guys told me straight that "Old guys know nothing of computers". As it happened I had a PropASC board in my pocket. I pulled it out and asked them what it might be. There followed a two hour discussion of micro-controllers and programming. Things they had never imagined. I was kind of pleased they were totally fascinated by the idea and had many smart questions to ask.
As we parted I had to say "It seems young guys know nothing of computers"
I wrote a letter. He probably won't see it. But maybe.
The content of it boils down to some money going to tech. Gotta get it in front of people. Some goes into basics, like that field guide type stuff I linked. People don't always know what computing is. They just know what it does.
And the rest should flex. In my school way back then, this is what they did. And it worked really well. Those of us with keen interest and skill got to do stuff. I can't begin to explain how high value that was. The educator had the freedom and enough resources to enable us and hold us to finishing things.
Even back then, as a kid, I could tell people were really different. Some were going to be systems people, some low level, others users, etc..
None of that has changed. People haven't really changed.
It should be all about giving everyone a go, and then enabling those that want to continue. Sort of like public speaking really. We make everyone do it, and for most the outcome is ordinary, "I can do this", for some it's terrible and they are done, and others are great somehow.
If we don't give everyone a go, some of us won't realize we are great, and a lot of us won't realize we can do this stuff too. As a people, we just miss out.
If I were king, that's what I would do with the money.
Looks like all the loops we need are covered. Is there a CASE?
No CASE.
FreeBASIC has this CASE syntax, so this gives an expansion pathway, for PropBASIC, if it is decided as necessary.
Syntax
Select Case expression
[ Case expressionlist]
[statements]
[ Case Else ]
[statements]
End Select
or (smaller/faster)
Select Case As Const integer_expression
[ Case constant | enumeration ]
[ statements ]
[ Case Else ]
[ statements ]
End Select
Note for C users: In FreeBASIC, Select Case works like a switch block where all cases have a break at the end. As there is no fall-through, multiple options must be put in an expression list in a single Case.
Besides integer types, floating point and string expressions are also supported with the first syntax.
Comments
Except there were no text editors when BASIC was invented. Hence the built in line editor in the interpreter.
Edlin is new technology, came over a decade later.
Ah yes, the printer port. The 8255 parallel I/O chip driving that was about the only thing that made a PC useful back then
Better late than never!
Isn't this the crux of the dilemma, that while it compiles PASM it is limited to 496 instructions, that's it. To be really useful in this same manner the P1 would have to be a P2, which it ain't, so perhaps PropBasic will come into it's own as many other languages and tools will when P2 is out.
Here's an example. I don't have a CS background, nor am I an engineer, and I'm really hesitant to post code that I've written or a hardware design but I think someone needs to show that PropBasic can be a serious tool. I don't hold this up as an example of how to do anything except include WAY too many comments (intended for me and my lousy memory), and if I started over I'd probably do some things differently. That said, it's a fairly significant application in PropBasic, in fact the most complicated thing I've ever coded. It's a GPS-based video timing overlay that reads GPS NMEA time info, phase-locks a Silicon Labs Si504 oscillator (now EOL, sadly) to the PPS and generates an internal timebase from which the overlay info is derived. I modified Bean's video driver to be an OSD, using sync from a LMH1980 sync separator. This has a LMM main program and the other seven cogs run cog code. I'm not one to post videos and such or I'd post a demo showing that it really does work. And I wouldn't have had a prayer of coding this in PASM.
If you critique the hardware or the code, please remember I'm just a tinkerer and there may well be blunders. If it weren't for this discussion, I'd never have posted this. The take home message is that not being an engineer or programmer, I could still take on a (for me) very challenging project and get it working. Don't even ask how long it took
[edit] typo
I've now uploaded a bit of video so you can see what it does.
The video is directly captured with no audio, and the background is sync plus black level so all you see is the output from the overlay generator. The little demo shows it waiting for the PPS pulse interval to settle down (despite claims, they are frequently erratic for several seconds and the code has to see 10 consecutive seconds of stable output), checking the NMEA time for a monotonic count sequence (again, 10 seconds without a hiccup) and then locking to the PPS. The format has the time in HH:MM:SS plus fraction for both fields of the frame. At the lower right is a running field count. The generator was intended mostly for time-stamping video shot through a telescope (asteroid occultations, primarily) so it would normally be over a starfield. The display format is mostly for historical reasons. An overlay generator that was commercially available for several years originated that display format and I used it just so anyone who had to do timing analysis of one of my video records would easily recognize the format.
Once the thing locks to the PPS, I run it through the various adjustments: brightness, vertical position of the time display (to accommodate monitors that chop off the end of the field, or to allow the display to be at the top), display width, and centering. A raw NMEA sentence display is next, followed by a screen that shows the loop behavior with time error on the top and frequency offset below. The offset isn't an error, per se, since I tweak the oscillator to keep the Prop clock locked to the PPS. It bounces around a bit, partly because the Garmin GPS PPS signal is only stable at about the 100 ns level, and partly because the Si504 oscillator's minimum adjustment interval is 2.4 Hz (0.149 Hz in the datasheet, but multiplied by the Prop's clock PLL) which is too coarse for a really accurate adjustment. Since the LSD of the time stamp is 100 us, an error of tens of nanoseconds is perfectly adequate.
The last screen looks pretty bizarre. It's an attempt at giving a user a way to confirm that the timestamps are accurate (assuming the GPS is accurate). The flash every second is actually the PPS signal itself, injected onto the video, and the idea is that the user would single-step through a video record until reaching a field where the leading edge (top) of the PPS "block" is on the graticule. The graticule provides an easy way to tell which scanline the leading edge falls on, then using the horizontal line time of 63.5 us for NTSC or 64.0 us for PAL, the time between the current field's vertical sync (corresponding to the time stamp) and the leading edge of the next PPS can be calculated. If that time interval is subtracted from 1 (since the PPS is for the next second), the result should be equal to the time stamp for that field, +/- 1 least significant digit.
Any adjustment that's made is written to EEPROM so it survives a power cycle.
I hope this is an adequate demo & explanation without further hijacking Bean's thread.
[edit] I obviously don't have your background, Peter, but that's partly the point of this discussion. No one would doubt that someone with sufficient background can get good performance out of the Prop. But what about the rest of us? Is a EE the price of admission?
I'm multitasking here but I'm simply saying something that Bean is very well aware of, that the nice fast cog code is limited.
The reason we have languages and tools is so that we can build apps. So the measure of the approach is how well apps can be implemented on the limited resources of the P1.
"fast" can run all over the place. LMM code is not COG code, but it's not SPIN code either, thus "pretty fast" and arguably, fast enough for a whole lot of things.
As for lean, another day. There are more axis to that than are currently being allowed for in this discussion, and it's a PBASIC thread anyway.
P2?
Yeah, this can shine on that one. When it's closer to being real silicon, good times!
Of course it looks nothing like BASIC. I'm not sure whey PropBASIC has "BASIC" in the name. Except of course I guess it is using line breaks as a major part of it's syntax, not free form like C'ish languages.
As I said, I kind of like the idea of a single operation per expression. It's something I considered when I first thought about writing a compiler years ago. Before I got lead astray by the concept of recursive descent parsers, operator precedence, etc. See how easily allowed Jones to comment every step of the way.
I like the idea that "if" cannot do assignments. This is clean. No side effects.
I like that it can produce LMM as well as raw PASM. Peter will say that is not "lean". True enough all those 32 bit instructions are big and some kind of byte code thing would help. But it is "lean" conceptually and pretty speedy.
I like that "if" always needs "endif". Unless it's all on one line. (as far as I can tell that is so)
I presume this cannot support recursive function calls. No worries, MCU programmers hardly ever use them, if they even know how. Recursive is for academics and CS students who want to show off their Ackerman function coding skills
Of course there are some things I would have done differently:
I would use LET for introducing variables:
LET LONG x = 10
Named parameters to functions with the usual round brackets would be nice.
Is there a "while" loop
while x < 10
...
...
loop
I have to look at this some more.
From docs.....
PropBasic 00.01.43
DO...LOOP
DO WHILE var cond value
LOOP
DO
LOOP UNTIL var cond value
DO
LOOP ' always loops
DO
LOOP var ' Loops var times, var = 0 when finished
Dave
The other day I wanted to do a Windows installation, man was it a pain to find the binaries, again. Since this thread might turn out to be an active one, stays up front for awhile, could you place the latest usable binaries in the first post along with the docs. Or maybe some other way of getting to the binaries and docs could be made; it seems like DropBox is being used quite a bit.
The documentation, looking at the actual size of the pdf file, I think it is what, 100 pages or so. Maybe if you got rid of a lot of the white space, the size, could be reduced too maybe 20 pages or less. I would also recommend maybe some more examples, it seems like "COGSTART taskname{,var}", could be made more explanatory.
Not sure what the progress with PropBASIC and Propeller IDE is, maybe a rehash of the different methods of working with PropBASIC could be in order. That could probably be the first thing that somebody looks at in your doc file.
Just my two cents, for whatever that is worth.
Ray
I was about to say there is no FOR, this really isn't BASIC. But then I found it
FOR X = 0 to 10 STEP 2
...
NEXT
Phew!
Hold on there. EE is the real world of device physics. It is only when you cross over into CS that you find all of the man-made rules (compilers, language syntax, interpreters, etc.). While some enjoy dwelling in that space, I find it a necessary evil.
CS is all about computers and computing. That is the theoretical investigation of what they can do and how fast they can do it. Algorithms and algorithm analysis. Actual hardware or actual programming language are somewhat irrelevant to all that.
All that practical stuff about languages, syntax, parsers, code generators is Software Engineering.
Most of us know little of any of those things. We just hack what we can, learn what we have to, until it works.
Of course there is a lot of overlap in all of these things.
And especially when messing with micro-controllers, driven by software, which are connected to electronics, which are connected to mechanical things, all of which we are trying to make for ourselves there can be a lot to assimilate.
Hence the need to keep it simple. For those who don't have huge amounts of time to invest into learning details they don't need to know to get things to work. Hence things like BASIC, Spin, Python, Javascript....
Guys, I didn't mean to hijack the thread, only to offer an example of a significant (to me, anyway) application to counter the impression that PropBasic is just for little demos or toy programs. I suppose I should've also pointed out that those eight files are all one "app", main is LMM in cog 0 and it loads the other seven task files into the other cogs. Also note that my coding style makes it all look a lot more verbose and cluttered than it needs to.
Bob
No CASE. You can get some of the functionality by using ON-GOTO or ON-GOSUB with an explicit list of values to compare against. A significant limitation is that with ON-GOSUB you can't pass parameters to a subroutine.
Didn't mean to be that specific. I was referring to having at least an undergraduate degree in engineering, computer science, etc., IOW having a lot of the background training that Heater mentioned, as opposed to those of us who might read a book or just dive in. For example, after many years of tacking chips together, I can generally figure out how to get chip A to work with microcontroller B and get enough out of a datasheet to write a driver and get it working, but if there are subtle issues that require extensive test equipment, lots of background, or tricky code I may be in over my head. You can probably tell from my code that I take a fairly simplistic approach to things.
I should also acknowledge that there is "lean and fast" for folks like Peter and there is "lean and fast" for folks like me and I'm well aware they aren't the same thing. If I can cram the needed functionality into a cog, I couldn't care less about optimization and/or elegance. If it works, I'm good.
Some years later, having graduated in Physics, it seemed he was right. The many of the EEs I knew could not tell one end of a soldering iron from another.
A few years ago, I stumbled across a YouTube video where some EE lab manager in a US university was lamenting the same problem.
Now of course it's good that someone knows all that intense theoretical stuff, but it use to be that kids arrived at uni having been tinkering with electronics since they were nippers. That's why they came to study EE.
Similarly, in the CS world world. The 1980's youngsters arrived at Uni for their CS studies and already knew how to program in BASIC and assembler, having been brought up on C64s and Sinclair Spectrums. They came enthusiastically to learn more. Now a days they arrive at Uni knowing nothing and it takes a year to get them up to speed. All they have is a vague hope of a well paying job.
So, we, happy hackers, I believe they call it "Makers" now a days can, in some respects, be far ahead of the EE and CS types.
Note: All the above is a terrible generalization but you get the idea.
It is really interesting to watch the GDC Classic Postmortem series. All these guys talk about their early experiences. Assembly language, constraints (and that 8 bit era was full of them), and how that forced them to reason about the task.
This is part of why I'm a fan of simple languages and when they offer up assembly language in a similar, simple way. All the good, higher level stuff, portability, etc... get ignored for a time in favor of basic literacy and fluency.
The result is something a person can reason about and get things to work.
Once it does work, they may get hooked, and once there, will progress as their skill exceeds the simple, enabling environment.
On that note, SPIN+PASM, being one unified, simple thing that also offered reuse in a similar, simple way, is brilliant.
Anyway, having a nice BASIC makes sense for those reasons. People may just want to do stuff, and if they can do it, they are happy. Some will want more. Others may just do more stuff. All good.
Maybe I'm weird but I soon found that quite a few things I wanted to do were much easier in assembler than BASIC!
Remember this is all being done via a teletype and acoustic modem to some remote mainframe.
It was a CS course. Only one third of it was anything to do with actual programming or computers, the rest of it was numerical analysis and statistics. After all, you need to have a reason for all this programming stuff right?
Which makes me wonder where Obama's 4 billion for point and click programming in schools is going to go. Nothing to do with CS. That would buy about 40 million Propellers or Raspi systems for school kids where they could get down to the real stuff if they want to. But that's another worm can.
This does depend on the assembly language some. Different CPUS have different sweet spots.
Also, it's fast. Often, it's not really necessary to optimize for peak performance. Just get it done. An old 8 bit BASIC is really slow. But, if it has inline, it can do a ton more. If it can be compiled, that's even better. People don't have to know much to make things happen, and it's the making of the happening that enables the making of the understanding.
(Yes, I wrote that for your entertainment Heater...)
And when it comes to special hardware features, being able to write assembly, quick, lean, fast can make them more accessible and useful as one can more fully exploit them. In this microcontroller / embedded space, I see that as just as relevant today as it was a requirement to make 8 bit computers do anything interesting at all.
When it's packaged up into a keyword or library, that may not all be true, and it's more frequently true for "off label" uses. (A good example is the standard video library I owe Brett. To fully exploit a P1 takes assembly language or a skilled programmer using compiled COG code. But, some general cases make sense.)
The cost is portability.
And that, right there seems to be the fault line related to inline and assembly in general. If doing that gets loaded up with other features to improve on portability, the quick, lean, accessibility goes out the window. But, it's still fast and able to directly exploit hardware.
If it is super easy, it's generally not portable, but then again it's super easy, so it's not as big of a deal to rewrite or modify code to fit too.
And, doing it is discouraged overall. As it should be, but for those cases where it can make good sense. Again, in this space, it often can.
I love it. Being an old guy now I have this weird urge to make some happening that leads to the making of the understanding among the youngsters I meet. I'm not very good at this.
On one recent occasion a couple of nice young guys told me straight that "Old guys know nothing of computers". As it happened I had a PropASC board in my pocket. I pulled it out and asked them what it might be. There followed a two hour discussion of micro-controllers and programming. Things they had never imagined. I was kind of pleased they were totally fascinated by the idea and had many smart questions to ask.
As we parted I had to say "It seems young guys know nothing of computers"
I wrote a letter. He probably won't see it. But maybe.
The content of it boils down to some money going to tech. Gotta get it in front of people. Some goes into basics, like that field guide type stuff I linked. People don't always know what computing is. They just know what it does.
And the rest should flex. In my school way back then, this is what they did. And it worked really well. Those of us with keen interest and skill got to do stuff. I can't begin to explain how high value that was. The educator had the freedom and enough resources to enable us and hold us to finishing things.
Even back then, as a kid, I could tell people were really different. Some were going to be systems people, some low level, others users, etc..
None of that has changed. People haven't really changed.
It should be all about giving everyone a go, and then enabling those that want to continue. Sort of like public speaking really. We make everyone do it, and for most the outcome is ordinary, "I can do this", for some it's terrible and they are done, and others are great somehow.
If we don't give everyone a go, some of us won't realize we are great, and a lot of us won't realize we can do this stuff too. As a people, we just miss out.
If I were king, that's what I would do with the money.
Sorry for taking the thread off on a tangent.
FreeBASIC has this CASE syntax, so this gives an expansion pathway, for PropBASIC, if it is decided as necessary.