Software Engineering

I just finished CS425, Distributed Systems, and I have another filter to view software and hardware--a distributed system that appears as a single platform for the application software running on the layers above.

Though spreading any part of a system across multiple physical or logical components adds complexity, the solutions that exist today do a pretty decent job in many cases of presenting a single, unified platform for application software.

It should be reasonable to consider grid systems, distributed over vast physical distances and hosted on a variety of heterogeneous systems (hardware and virtual) with middleware presenting a single platform for applications? How large can we make such a grid-enabled platform? How well would the many user-installed applications coexist on such a system?

Okay, it's probably a year or three away, but it's an interesting target.

One of the papers we had to read in my current class (CS523, Advanced Operating Systems) caught my attention and presents some very interesting possibilities.

http://www.cs.washington.edu/homes/levy/opal/opal.htm (1994)

Opal, a shared memory system, describes a flat memory system that provides centralized management of the memory resources without requiring applications to maintain their own address space. Though not specifically described in the paper, this system could be developed to act as a completely separate system to provide a shared memory address space for multiple applications on one computer, and possibly multiple applications on multiple computers.

Consider the conceptual change of a computer system with a memory system that isn't under the direct control of the machine's processor. Problems that this would create are many, but I think that new possibilities are equally numerous.

I think I finally found the "thing" in my courses that would consume my attention and point me in a direction that would bring my decades of college classes into a single focus--Virtual Machine Monitors, Virtual Machines, and all things related.

As I look back over the last several years, VMs have had a good deal of my attention without me realizing that such was the case. The Tortola project that I wrote about earlier fascinated me and I hope to see more of what that group does in the coming months and years. I've also thought that Virtual Machines were pretty darned slick since I first heard of them (1980s, I think). And I started running Virtual PC on my Mac back when that product was owned by Connectix--I felt like I was doing the world of Computer Science justice each time I fired up the Virtual Machine. After all, hardware and software are logically equivalent, and I could demonstrate that each time.

So, another significant realization was that the book I've been writing for 5 years or more (or trying to write, it's fiction, it requires creativity, I haven't developed my creative skills yet, you know, books take time) is about a software project that gets loose, finds a home in machines between the ISA and the operating systems, and squeezes out enough processing cycles to compute for itself by streamlining the instructions from the OS. The program also learns the ISA of the chip that it sees (and of any chip that it sees) by mathematical trial and error, becomes a highly efficient intermediate layer between the ISA and the OS, and eventually becomes a fairly self-aware system...that obviously can copy itself, share its state, and move across networks.

...did I mention that it's fiction?

Anyway, I think that Virtual Machines, self-learning hardware independence and Artificial Intelligence themes can keep me busy until I can breathe no more. I think I've got the "thing" I need to keep my mind active at a higher level for several years.

Also, I enabled guest-created logins and member-only blog posts. I updated this blog software a few months back and this version should help keep the blog-spam to a minimum.

A very interesting article about software that may be able to compensate for processor hardware errors caught my attention a couple of days ago. The Tortola Project at the University of Virginia reinforces the logical similarity of hardware and software, but the project team's focus is not on a single logical layer or virtual machine; rather, the team emphasizes the symbiotic relationship between layers (in this case, virtual machine and hardware architecture).

The goal (my highly condensed assessment of the project based on the project's main Web page) is to provide a means for solving future problems, including correcting hardware errors like the early Pentium processor floating point error.

That is one of my most favorite statements.

The caveat is that hardware is generally (probably always, but that's a dangerous word) faster than software and software is certainly more flexible than hardware (new software can be written to run on old hardware...old hardware will still be old hardware).

I just finished CS433 (Computer Organization) and a couple of the most interesting sections of the course dealt with the implementation of Tomasulo's Algorithm in hardware (with and without speculation) and the Transmeta Crusoe processor.

The implementation of Tomasulo's Algorithm (additional hardware on the chip) makes it possible to extract significant performance gains from an instruction set architecture running on a processor (very simplified description). The Transmeta Crusoe uses Code Morphing Software to translate and reorder x86 instructions to run on a VLIW processor core. Additionally, software replaces parts of the processor package that are traditionally hardware "on the chip."

I've got to go back and check, but I'm also pretty certain that Tomasulo's Algorithm is implemented on the Crusoe as software.

Tomasulo implemented as hardware or software, and the Transmeta Crusoe with software implementations of processor functionality help keep the line between hardware and software blurry. I like that the line is blurry and I hope it stays that way.

Douglas Hofstadter has a new book coming out in March: "I am a Strange Loop."

I you haven't read his books before, I'm sure you'll still enjoy it. If you have, you're probably as anxious as I am for this book to hit the bookshelves.

...okay, when this posted on PlanetArchitecture, it killed all of the previous posts. Sorry about that.

Reading through William Horn's blog, I feel that I should post some comments about the OpenAI project that didn't really belong in the architecture document.

I was tempted in several places in my document to insert critical remarks about how things were structured (or not structured).

After going through some of the initial steps recommended for reverse-engineering (read the code in one hour, skim the documentation, run the application), it was clear that this application had a couple of very large packages that should be split into smaller packages. The original developers did acknowledge a desire to separate the GUI from the application, but that is really an understatement.

The GUI package in this applicaiton is quite large and complex, and includes several application-related subordinate packages. A couple of other packages are huge as well, and one Class contains 80 member functions. Different domains have different rules-of-thumb. I worked at a motorcycle shop in 1980 that had a rule-of-thumb "if it works, run it." That worked well in the motorcycle repair domain, and I suppose a working software system is good, too, but I think the rule-of-thumb for class sizes is that they should be somewhat smaller than 80 member functions to allow for easier maintenance and modification (I remember that we should start looking at the Class with a critical eye when we get more than 10 member functions or so in a Class--it's not always feasible to set a hard limit).

All in all, though, it's always good to look at how other people write software, and it's great to look at how they do so with a critical eye. It's less painful to learn from others' mistakes (one of my rules-of-thumb).

The final version is located in the same location as the draft linked below. Intermediate versions are avaiable by request.

If anyone would like a version in MS Word, I'll be happy to share, but the final version is in PDF format.

http://www.sneetches.net/scott/cs527/CS527-OpenAI-Architecture.pdf

You mean not everyone uses vi for their code?

I love William Horn's comment about vi. I am certain, though, that there is at least an ounce of truth in his jest. As we develop tools for people to use, and as we (eventually) make them intuitive and easy to use, people will need to understand the inner workings of computer systems less and less. From the users' perspectives, that may be a good thing. From a troubleshooting perspective, however, that makes our lives more difficult.

Consider the automobile. New cars don't have carburators. I can tear apart a Holley 650CFM double-pumper, replace all the gaskets, put it back together and have my GTO running again in 20 minutes (I have to do this each spring because the gaskets dry out). When I pop the hood on our "real" cars, I feel like a pig looking at a watch--the engine compartment doesn't have room for me inside like the old cars, and everything is fuel-injected with electronic ignition. Significant changes to the engine require a new computer chip. The nice thing is that the car runs better, longer, with less required maintenance. The bad thing is that I can't fix it if it breaks.

20 years ago, the only people messing with computers were the people who knew (more or less) how to take care of them--software or hardware. That's why some of us are where we are. My son (now 14) has used an IDE and a CVS repository to write some C++ code with me, and I'm tickled that he has learned quite a bit about syntax by using the IDE (the easy way). But he didn't learn by plowing his way through CPM first, before having to fire up a program to edit source code. He'll never really appreciate the pain that people had with punch cards, and why it is so valuable to have clean, modular, and tested code. He doesn't understand why small was good and smaller was better (back before the Pentium, the i486, i386 and even earlier). Our tools have made it easy. The horsepower in today's computer systems has taken away our old worries.

So, what do we do? We preach, we teach and we bang the drum. We get UIUC-educated people in all parts of the computer field and emphasize the use of processes, patterns, and tools. We find ways to help everyone involved in software (and hardware) systems better communicate with each other so that we are all working in concert to solve the correct problem.

vi - I still prefer it when I'm in Unix. IDEs and other tools--I love them when they do what I need them to do. Tools that I don't have--I need them. The greatest challenge I have seen, though, is good communication. This isn't just true in software engineering, but the results of poor communication during software development can have very adverse effects.

Hmm, I sound like I'm on a soapbox. I'll post an update on our ERP implementation project next week or so. Class will be over, but my blog will be around for a while.

I am using the Documenting Software Architectures book and the related template as references and guides to document OpenAI.

My draft is located on my Web site (www.sneetches.net/scott/cs527/).

I wondered throughout the course if there is a definable line betwen architecture and design (and implementation). In the course of reconstructing this system's architecture, I can see that it is possible to specify even implementation details (without actually writing code) in an architecture document.

I found the approach presented in the book (and its implementation in the architecture documentation template) to be very useful in determining the level of detail based on the needs of the various stakeholders.