This article is prompted by the recent news of Gnome considering a vote to split from the GNU project. The GNU project is a software development effort to create a free Unix-like operating system. Indeed, much of the software tools used in Linux (a Unix-like operating system) was created by the GNU project. Much of the philosophy of the GNU project came from its founder, Richard Stallman. Stallman advocates that free (as in freedom) software is the only acceptable kind; any software that removes a person’s freedom is an assault to that person’s inalienable rights. Stallman’s definition of freedom includes a person’s rights to run a program for any purpose, to redistribute the program (either for no cost or for a fee), to modify that program to suit his needs, and to distribute the modified program.

A bit after the GNU project had gained some momentum, Linus Torvalds saw the use of the software tools created by the GNU project. Torvalds had been working on his own project: an operating system kernel called Linux. The GNU project by that time (around 1991) had released some quality software, which Torvalds saw fit to include with his operating system.

Over time, the GNU project also created a software license called the GNU GPL. The license codified Stallman’s philosophy into a legal document. It included terms that required distributors of GPL-licensed software to also distribute the source code to that software. Also, any GPL-licensed software that was modified also had to have the modified source code distributed with the with it. Torvalds wanted to distribute Linux for free and realized that having any modified versions of his code would be beneficial, since he could then incorporate that modification in his own system. Because of this, Torvalds released Linux under a GNU GPL license. Many other people followed suit.

At that moment, two different people with different goals shared a similar means. Ever since then, people of one mindset or the other would associate themselves with the seemingly same community. They called it the Free Open Source Software (FOSS) community. It has seemed to work okay for a while, although there has always been some amount of friction between those who are in it for pragmatic reasons and those who fight for the human right to free software. The pragmatists are making deals with companies that produce proprietary software. The GNU crowd is making very public, very bold statements that don’t represent the views of everyone involved. This friction has begun to start fires.

Arguing for one viewpoint or another is not going to tear “the community” apart, as some people believe is happening. This is not a community to be torn apart; it is two different communities, and it’s time for people to realize that. I do believe that once this becomes accepted, people will be much happier and more productive.

What do you think? Two communities? One community? Post your comments.

In my communications for engineers class, we had an assignment to write a paper in the style of a technical journal in our industry. Since the subject of extensible processors has recently caught my interest, that was the topic of my paper, and of course, it is in the IEEE Transactions format. You can download and read the paper here.

In my previous post, I mentioned an article where the author suggested using customized processors to implement a system on a chip. Another interesting topic is somewhat related, but from the opposite direction - the subject of extensible processors. It involves the improvement of general processors by adding custom logic.

Microsoft Research has an architecture they’ve developed called eMIPS, which takes a MIPS processor and adds an FPGA that has access to each datapath stage. This allows for a dynamically reconfigurable bit of logic to implement custom instruction extensions. There are even tools that enable you to pick a block of machine code out of a program and automatically generate the custom logic to implement it - this is done with software tool called MIPS-to-Verilog. Using another program (BBTools), the new instructions that invoke the custom logic are automatically inserted into the program and the original code stays there as a software fallback. This software fall back can be useful if, for instance, the operating system didn’t allow the program to add the custom logic because a higher priority program was already using the FPGA extension.

I would also point out that this setup resolves the CISC/RISC dilemma. Some processing tasks which can be done on a simpler RISC architecture can be done much faster if these tasks are implemented directly in hardware (leading to a CISC architecture), however, there are very many such tasks: choosing the ones that make it into an architecture is difficult. Additionally, every task that is implemented complicates the processor and makes it more difficult to debug and generally optimize. Since an extensible processor can have the custom logic reprogrammed on the fly, the programmer (or perhaps a sophisticated compiler) gets to insert whatever additional logic is needed.

I routinely read EDN and EETimes. There are an abundance of articles on these sites about SoC (System on a Chip) design that talk about things like ESL and EDA. These articles have been over my head since I have not yet done SoC design. I took a class on MEMS that included some interesting content about SoCs, but it covered more about what they are, their applications, and some fabrication challenges. Finally, I have found an article that has a good overview of how the design process works.

The author talks about ESL design and algorithm synthesis, which is a software approach to SoC design that takes a high-level algorithmic description (typically written in C) and converts it to RTL logic. He points out that this is not the only approach to system level design: instead, you can use customizable processors (which can directly run the C code) to implement algorithms in an SoC. This is very interesting and something I would definitely enjoy doing because I love programming, microprocessor architectures, and logic design.

This article is intended for people familiar with computer programming.

Some languages support a feature called object literal notation. JavaScript is one such language.

Statements such as: x = 5; or name = "Shawn"; are common in programming. The part on the right (5 or "Shawn") is called a literal. (Technically, the literal is Shawn and the quotes are metadata which tell the interpreter or compiler what its type is.) The first is an integer literal; the second is a string literal. In some respects, it is like a constant. 5 is always 5: you can’t change its value. Unlike a constant, a literal’s value is immediately obvious upon reading it - its name is its value. Such is true in an object literal.

Here is an example of an object definition in JavaScript:

var person = new Object(); person.name = "Shawn"; person.addFriend = function(friend) { //add a person as a friend }
This example does not use object literal notation. It creates a basic object, then modifies it by adding properties and methods. Sometimes it’s useful just to define the object instead of to create one and modify it several times. This is done with object literal notation.

var person = { name: "Shawn", addFriend: function(friend) { //add a person as a friend } }
Note that everything after the equals is a literal. Since the literal is of type object, it is an object literal.