Showing posts with label C Language. Show all posts
Showing posts with label C Language. Show all posts

Sunday, April 17, 2011

Vala a modern language for embedded, validated with VCC for C?


I'm always in search of the mythical 'Silver-Bullet' language that will let all of us write bug free software for our Embedded Systems. This week I came across Vala. Vala is a new programming language that aims to bring modern programming language features to GNOME developers, its syntax is taken from C# amd Java. What piqued my interest is that Vala is a front end that compiles to native C code. So there is some hope that it would be run on an Embedded Micro, tho it would have to have some beefy memory to support GObject.
Some of the features of Vala are:
  • Assertions and Contract Programming.
  • Signals/Asynchronous Methods; With asynchronous methods it is possible to do programming without any blocking. [Yes, the masochistic could do this with raw function pointers.]
  • Anonymous Methods / Closures.
  • Multi-Threading.
  • Resource Control.
Still there are a few kinks I see in Vala. The Vala Tutorial gives some examples of where the language will let you shoot yourself in the foot. A language should do all it can to prevent errors by the programmer. If we want to use a language that lets us shoot ourselves in the foot we can keep using forty year old C, or Programming A Problem-Oriented-Language by Charles H. Moore, written ~ June 1970.

I don't know how close Vala's asynchronous queues are to a true message passing system like Erlang. Hopefully close enough to have to avoid the whole issues of threads and locks, but I don't think this is the case from look at a bit of the code. Threads and locks simply do not scale, especially after you get past about 64 cores. Linux multi-core scalability is a good paper to start with on the issue. I'd like to see a language similar to Vala that enforced single assignment variables and true message passing, that complied down to something that ran on our small micros.

Chips with 144 independent F18A computers are just starting to come on the market now, so we collectively need to get our acts together on doing multi-core programming, without archaic notions of shared variables, threads and locks.

Something else I came across this week over at CodePlex was VCC from Microsoft: "VCC is a mechanical verifier for concurrent C programs. VCC takes a C program, annotated with function specifications, data invariants, loop invariants, and ghost code, and tries to prove these annotations correct. If it succeeds, VCC promises that your program actually meets its specifications."

I wonder how you could convince Vala to output VCC annotated source code to feed VCC to prove a 144 core program is correct on one of Chucks Chips? I do realize chips from Chuck Moore will be using Forth...

Anyone want to buy my Small-C Handbook collection?

My wife and I keep working at downsizing our home. We are tired of having our lives determined by "stuff". Move it from 'there' to 'here', spend time to inventory, dust it, move it back, etc. All of which takes time from our goals in Life.

[The Small-C book set below has found a new home, so they are no longer available.]

Anyway if anyone wants the following set of books I'll send them to whomever wants to pay for their shipping. I'll only ship to the Continental US, sorry. About five pounds shipping weight.
I just can't bring myself to toss this in the trash as they are still good teaching tools, and Jim Hendrix says Small-C is still being ported to devices to this day.
  • The Small-C Handbook by James E. Hendrix.
  • Small-Mac User's Manual for CP/M Release 1.2.
  • Small-Tools User's Manual for CP/M and MS/PC-DOS Release 1.2.
  • Dr. Dobb's Handbook of C. 700+ page hardback in like new condition.
  • Dr. Dobb's Journal A small C Compiler for the 8080's and Runtime Library for the Small C Compiler by Ron Cain. Reprint, with permission, from the May and September, 1980 issues of Dr. Dobb's Journal.
While I'm in a selling mood, if anyone wants to acquire the domain name dsPIC.org for any dsPIC projects send me an email. Don't really use it, and it is just more "stuff" that needs maintenance once in a while.