Recently, Gary Stringham has been running a series of interviews with providers of register design tools on his website. Register design tools seems to be an active area with several small companies (and some open-source tools) fighting for the market. I have written about Gary Stringham and register designs before, and it is an area that keeps fascinating me. There is something about the task of register design that keeps it separate from the main hardware design languages, tools, and flows.The different approaches taken by the tools supporting the register design task also illustrates some points about programming language standards, domain-specific languages, and exchange formats that I want to address.
Tag Archives: Domain-specific Languages
For my parental leave, I have just bought myself a Lego Mindstorm NXT 2.0 kit. It is not much fun for our youngest, who mostly gets a bit scared by a piece of Lego driving around making noises, but I hope to be able to use it to teach my older child (almost five) to program. Let’s see how that turns out. It looks hard to make the NXT environment provide the kind of Roborally-style programming blocks that I had hoped to create, as I cannot for some reason get a sufficiently custom icon onto custom blocks.
It also presented me with an opportunity to try some domain-specific high-level graphical programming. The programming environment provided for the NXT series of Mindstorms kits is based on LabView from National Instruments, and it really does seem to work. It even features parallel tasks, which I tried to use…
In the April 2009 issue of Communications of the ACM, Mike Shapiro of Sun (or should we say Oracle now?) has an interesting technical article about what he calls “purpose-built languages“. The article was earlier published in ACM Queue. Essentially, it is about domain-specific languages. He describes how many of the most useful little languages in use for the developmentof large systems have grown up without formal design, a grammar, or even a name.
The 44th episode of the Stackoverflow podcast contains an interesting discussion on what I have liked to call “the tyranny of syntax”.They note that for some reason people are scared of anything that does not look like C, but still lament some of the less good design patterns in C, such as the fact that closing braces have no annotations as to what is being closed. They also talk about the use of “little languages”, and an old favorite song of mine.
The two days of the SiCS Multicore Days is now over, and it was a really fun event this year too. I will be writing a few things inspired by the event, and here is the first.
Kunle Olukotun‘s presentation on the work of the Stanford Pervasive Parallelism lab included a diagram where they showed a range of domain-specific languages (DSL) being compiled to a universal implementation language. That language is currently Scala, and in the end all applications end up being compiled into Scala byte codes, which are then optimized and dynamically reoptimized and executed on a particular hardware system based on the properties of that system. Fundamentally, the problem of creating and compiling a DSL, and combining program segments written in different DSLs, is solved by interposing a layer of indirection.
But this idea got me thinking about what the best such intermediary might be for large-scale general deployment.
In the July 2008 issue of IEEE Computer, there is short article called “In Praise of Scripting: Real Programming Pragmatism“, by Ronald P. Loui, a professor at Washington University (WUSTL). The article deals with the issue of what is the appropriate first language to teach new CS (Computer Science) students, and considers that a “scripting” langauge like Python or Ruby might be way better than Java (no doubt about that I think).
What can this teach us for the purpose of simulation and the creation of models of computer system hardware for the purpose of simulation? Maybe a fair bit…
The Radio Register has a nice interview with Kunle Olukotun, the man most known for the Afara/Sun Niagara/UltraSparc T1-2-etc. design. It is a long interview, lasting well over an hour, but it is worth a listen. A particular high point is the story on how Kunle worked on parallel processors in the mid-1990s when everyone else was still chasing single-thread performance. He really was a very early proponent of multicore, and saw it coming a bit before most other (general-purpose) computer architects did. Currently, he is working on how to program multiprocessors, at the Stanford Pervasive Parallelism Laboratory (PPL). In the interview, I see several themes that I have blogged about before being reinforced…