Creating a SPIN compiler for AVR chips..
LoopyByteloose
Posts: 12,537
I know... this is a very odd idea.
But why not introduce the OpenAVR crowd to the merits of SPIN on their own silicon?
But why not introduce the OpenAVR crowd to the merits of SPIN on their own silicon?
Comments
What merits of Spin?
What would Spin offer an AVR user over C++ ?
The Arduino users seem to get by very well with that combination.
And, with the comprehension of SPIN, these users might see that having 8 cogs (or 16 cog) might even be best.
I'm not saying don't for it but right now, even the P2 debates appear to be a more rewarding pastime than this!
But SPIN really provides the means to put together i/o object that were partially or entirely written in ASM. Maybe SPIN would help the AVR crowd actually write some i/o code rather than expecting either the silicon to provide or someone else to write code for such.
It would be a great way for introducing the Parallax point of view.... greater empowerment through deeper understanding of what the underlying architecture could do.
(Since I learned to program on the BS2 and the Propeller, C++ is a non-issue.)
Ugh? Pretty much every driver for everything in the world is written in C by C programmers.
I would wager that the majority of micro-controller code is written in C rather than assembler now a days.
Drive 32 R/C servos at the same time!
Auto-update multiple strings of smart RGB LEDs (like NeoPixels) without taking time from the mainline animation code. In fact, the Propeller could receive DMX data at the same time and use it to control the LEDs as well.
I'm playing with a personal project that uses Dynamixel accumulators, standard servos, does PWM of LEDs, and sends serial data to an external device. The Arduino is just not up to the task for this project.
I do realize the thought of porting SPIN to other single CPU devices was a bit of a stretch, but trying to pry the herd away from their C or C++ mindset for everything is difficult at best.
I really don't think every driver is written in C as Heater claims. They are written in Assembler with a C interface because the average C programer doesn't want to think about assembly language.
You're funny!
Python and node.js are a treat to use on the Raspberry Pi.
Spin's beauty is how well it integrates with PASM and the hardware itself. It is matchless when it comes to achieving that goal. Once you take away one of those components, it's just back to being another quirky language.
Thanks for not taking this thread too seriously. It is just so easy to get Heater screaming bloody murder... I couldn't resist taking a poke in his direction.
Now... What is to there to appreciate? It's just another crude and simplistic language in the style of Pascal or C etc. Apart from the funky object thing that leans toward C++. Not that I think that is a bad thing. It's great at what it does on the Propeller.
As pointed out above the glory of Spin is the tight integration with PASM and the Propeller. That all vanishes when you move it elsewhere.
The Raspberry Pi guys have more choice of languages to use than you poke a stick at anyway. Why would they need YAFL? When the herd has C or C++ or Pascal or Ada, etc, why would they need Spin? It offers nothing over those other choices. Do check out the Linux kernel source code. It is stuffed full of drivers. Most of them written in C. There is amazingly little assembler in there. I would be curious as to how Windows drivers are written but that is not likely to happen.
In my experience of the embedded systems world very little code, drivers or otherwise, is written in assembler anymore. I have no idea where you are getting your "average C programmer" form but most of the ones I have worked with grew up with assembler and can take it in their stride. They just realize that it is rarely a sensible thing to do now a days.
I haven't taken many threads seriously lately. Unless it says "I'm working on this REAL thing and want to know how to....", it's all smoke and mirrors these days.
I'm into tangible lately...everything else seems to leave an empty feeling.
Not really true. It may be "little" in SLOC percentage terms across all programming domains, but it is not "little" in either SLOC or significance in the deeply embedded domain (which by the way doesn't include anything based on Linux or Windows - or typically any O/S for that matter).
Even the TIOBE index still has assembler at #17, and it's on the rise again - perhaps as we have more and more embedded devices. And once you get outside the "top 10" languages you are looking at very minor differences in percentages - they are all around 1% or 2%.
In the domain where the Propeller is targeted (i.e. deeply embedded) you will find lots of code is still written in assembler. Hard to get an accurate figure - but in my experience it would average something like 20% - 30%. In some instances it is still 100%.
Ross.
You do realize that C was initially conceived as a "portable" assembly language so that programmers did not have to learn a multitude of proprietary assembly language don't you?
The Propeller has more I/O pins which is pretty handy. It also has much more RAM which is useful when you need to buffer data before uploading it to a PC. But the AVR chips have a much simpler, architecture so it's easier to get them operating at their full potential. I don't think I've ever had more than four cogs in flight at one time on any project. So I have never really used the Propeller to its full potential.
Well then why is it typed? Assembly isn't.
Because it enhances productivity, maintainability and readability ... and costs nothing.
C is what used to be called a weakly typed language. These days the terms weakly and strongly typed are not used much - we would instead say that C only does limited static typing, which is done only at compile-time and adds nothing to the overhead of the language. It does not do any dynamic typing, which has to be done at run-time.
Ross.
In the various environments that I have worked in where there is a lot of "deeply embedded" work going on the majority of code was in a HLL, from top to botom, application to drivers. Often with no operating system at all. It'a amazing what guys can do with an 8 pin PIC or AVR and a C compiler. Then we have things like the ADA projects where somone might have to fix up a bit of assembler at the Ada run time level.
All in all not much assembler code about.
True enough that in the Propeller world there is a much bigger proportion of assembler. It's the only way to get performance in Spin!
@Electrodude, Because it makes writing the compiler possible.
In assembler you do indeed have types.
In many CPU architectures and hence assemblers there are different instructions for operating of different sized variables. Bytes, words, longs, 8, 16, 32, 64 bits. whatever. The Propeller does not have this apart from the HUB read/write instructions but never mind.
Further there may be different instructions for dealing with signed or unsigned variants of those diferent sized variables.
Now, in a high level language you may want to write: And be able to write it the same way no matter what size or signedness z, x or y may have.
That means you have to tell the compiler what size those variables should be so that it can generate the correct machine instructions. The way to do that is a attach a type definition to variable declarations. How else would you do it?
Clearly you need to have those types if only to get data laid out in memory efficiently.
All that guff about "enhances productivity, maintainability and readability" is bogus. You need types in order to be able to build the compiler that generates the code you want. All that other stuff is misguided marketing double speak that is probably not even true.
P.S. I'm not really with this C is a "portable assembler" idea. Did the creators of C really describe it that way? I always thought it was something of a put down invented by the inventors of other "real" high level languages like Ada that came later.
In general No, there's not - but in embedded, Yes there is - still!
No it's not.
Yes it is.
No, it's true - that's exactly what it was designed to be. And it is described as such by Richie himself, in his Bell Labs "The Development of the C Language".
Ross.
+10. If there's something I learned from Laura Schlessinger (when I listened to her 10-15 years ago) it's that you can't change others but you can change yourself. So I decided a while back to stay busy building, doing, and learning interesting things all day long. It has proven extremely satisfying. The 21st Century is a great time to be alive if you can filter out all the idle nonsense.
According to Kernighan and Richie, the C language does not have any i/o features, that is all provided in the libraries. So I don't quite see how you can define it as a 'portable assembly language'. And it seems to me that assembly language merely creates mnemonics to represent machine code. It doesn't abstract the machine code into a series of conventional concepts; such as do loops, for loops, goto statements, arrays, and so on.
And since, C doesn't have any i/o features, I am not exactly sure if drivers should be considered belonging to C or belonging to the machine code. It is hard to say, just because a lot of them are provided in .a files that hide how the code was created.
Becasue assembly language has no I/O features eirther.
Ross.
print ("Hello world")In the former case the "print" is a keyword in the language and the compiler has to parse it, realize it is not a function call or variable refernece or whatever. It then has to treat it specially and generate code to do it. Clearly that "print" is in the language specification.In the later case "print" is just another function. The compiler handles it that the same as any other function. No special work required. That "print" is not in the language specification. The compiler need not know anything about it.
This clearly makes life easier for the compiler writers. It also adds flexibility because a programmer can now swap out the "print" supplied by the library that comes with the compiler or operating system with a different one.
So in this way there is no I/O in the C language.
However. C does have I/O functions and they are part of the C standards. So portable programs can be written. That standardizing of I/O was a major innovation at the time. ALGOL for example had no I/O in the language and no standard libraries defined. Every compiler provided it's own I/O function which were incompatible. Code was not so easily portable.
Conversely C does of course have I/O features. If I am on a machine that uses memory mapped registers for I/O, like OUTA on the Propeller, then C can read and write to that. So I can create that UART driver or whatever driver in C. With that I can make my "print".
It's a bit tricky if you have a processor with a I/O memory space that is not normally accessible from C. There you will need a few lines of assembler somewhere to write the IN and OUT instructions.
P.S. I should say Python had a "print" keyword in the language spec. In a recent version it was replaced with a "print" function.