Very few people want to invent the universe before they blink their first LED. Sure, with enough interest a lot of folks will drill-down to the atomic level of technology and build their way back up. But there’s something magical about that first time you got your blinky to blink, and knowing how to write makefiles plays no part in that experienc). Now apply that to projects using smartphone as wireless interfaces… how simple can we make it for people?
Jose David Cuartas is working to answer that very question and gives us a guided tour of his progress in this Meta_Processing workshop held during the Hackaday Remoticon. Meta-Processing is an IDE based on — as you’ve probably guessed — Processing, the programming language that unlocked higher-level functionality to anyone who wanted to perform visually-interesting things without becoming software zen masters. The “Meta_” part here is that it can now be done with very limited typing and interchangeably between different spoken languages.
The approach is to take the best of text programming and block programming languages and mash them together. In that way, you don’t type new lines, you add them with a click of the mouse and select the instruction you want to use on that line from a list. It means you don’t need to have the instructions memorized, and avoids typos in your code. The docs for that instruction will be shown on the bottom bar of the IDE to help you with parameters. And the kicker is that since you’re selecting the instructions, choosing any of the IDE’s 14 available spoken languages will update your “code” with translations into the new language.
People learn in many different ways. Having options like this to help people get to blinky very quickly is a great way to break down barriers to understanding and using computers.
The best thing about field-programmable gate arrays (FPGAs), when you have a massively parallel application, is that everything runs in parallel. The worst thing about FPGAs, when you need a lot of stuff to happen in sequence, is that everything runs in parallel. If you have a multi-step computation, for example, you need to break it up into chunks, figure out the timing between them, and make sure that each chunk clears before it is fed new data. This is pipelining, and taking care of all the low-level details yourself is one of the things that can sometimes make FPGA a four-letter word beginning with “F”.
[Julian Kemmerer]’s PipelineC is a C-like language that compiles down into VHDL so that you can use it in an FPGA, and it does the pipelining for you. He has examples of how you’d use it to construct a simple state machine, and after you’ve written a few hundred state machines the long way, you’ll know why this is a good idea.
PipelineC isn’t the only high level synthesis language out there, but it sits in an interesting place. It doesn’t take care of memory or define interfaces. It just takes care of pipelining. We haven’t tried it out yet, but it looks like it would be interesting for moderately complex projects, where the mechanics of pipeline signalling is a hassle, but you don’t require the deluxe treatment. Check it out, and if you like it, let us (and [Julian], natch) know.
If you stay up to date with niche software news, your ears may recently have twitched at the release of a new programming language: V. New hobby-project programming languages are released all the time, you would correctly argue; what makes this one special? The answer is a number of design choices which promote speed and safety: V is tiny and very fast. It’s also in a self-proclaimed alpha state, and though it’s already been used to build some interesting projects, is still at an early stage.
If you have ever worked in software-related industries, the chances are that the word “Rockstar” will elicit a visceral reaction. It’s a word used by a Certain Type Of Manager for an elite software developer who’s so 1337 they don’t play by the rules of ordinary mortals. In reality it’s use is invariably an indication of trouble ahead, either from clueless startups or troublesome rockstar developers making a toxic atmosphere for the mere members of the backing band. Hackaday has a team that brings together a huge breadth of experience, and we’ve been there.
Would you like to be a rockstar developer, but without the heartache? No silly incentives, or even guitars required! [Dylan Beattie] can help, because he’s come up with a specification for the Rockstar programming language, a Turing-complete programming language whose syntax follows the conventions of 1980s rock power ballads. Of course, it’s a joke, and an excuse of some “Certified Rockstar Developer” laptop stickers, but it’s also an entertaining journey into lyrical language and compiler parsing, and the discovery that yes indeed, a singable set of classic rock lyrics can also be a compilable program.
Our particular favourite comes from the scheme used to represent numbers, as sentences in which a decimal is built from the lengths of the sentence words, and poetic licence can be employed to the fullest. The example is
My dreams were ice. A life unfulfilled; wakin' everybody up, taking booze and pills
which line of code places the value 3.1415926535 into a variable called “my dreams”.
There does not appear to be a working Rockstar compiler at the time of writing, but we are sure that the amazing community of Rockstar developers will shortly create one. And we would be hugely disappointed were we not to hear some performative coding from spandex-clad guitar-wielding developers as a result. After all, how else will they get their work noticed!
Shared libraries are our best friends to extend the functionality of C programs without reinventing the wheel. They offer a collection of exported functions, variables, and other symbols that we can use inside our own program as if the content of the shared library was a direct part of our code. The usual way to use such libraries is to simply link against them at compile time, and let the linker resolve all external symbols and make sure everything is in place when creating our executable file. Whenever we then run our executable, the loader, a part of the operating system, will try to resolve again all the symbols, and load every required library into memory, along with our executable itself.
But what if we didn’t want to add libraries at compile time, but instead load them ourselves as needed during runtime? Instead of a predefined dependency on a library, we could make its presence optional and adjust our program’s functionality accordingly. Well, we can do just that with the concept of dynamic loading. In this article, we will look into dynamic loading, how to use it, and what to do with it — including building our own plugin system. But first, we will have a closer look at shared libraries and create one ourselves.
But data isn’t the only thing residing in memory. All the program code is accessible through either the RAM or some other executable type of memory, giving each function a specific address inside that memory as entry point. Once again, pointers are simply memory addresses, and to fully utilize this similarity, C provides the concept of function pointers. Function pointers provide us with ways to make conditional code execution faster, implement callbacks to make code more modular, and even provide a foothold into the running machine code itself for reverse engineering or exploitation. So read on!
In general, function pointers aren’t any more mysterious than data pointers: the main difference is that one references variables and the other references functions. If you recall from last time how arrays decay into pointers to their first element, a function equally decays into a pointer to the address of its entry point, with the () operator executing whatever is at that address. As a result, we can declare a function pointer variable fptr and assign a function func() to it: fptr = func;. Calling fptr(); will then resolve to the entry point of function func() and execute it.
Admittedly, the idea of turning a function into a variable may seem strange at first and might require some getting used to, but it gets easier with time and it can be a very useful idiom. The same is true for the function pointer syntax, which can be intimidating and confusing in the beginning. But let’s have a look at that ourselves.