Christmas Break TODO List
Happy Birthday to this website! It's been running in one form or another for the last three years. A lot has changed since then. Originally it was just a convenient place for me to put SkyOS programming guides. Now, it's a site about Programming, Alternative Architectures, and Open Source (and still a convenient place for me to put things I don't want to lose.) It's evolved quite a bit in the last three years. I've got it, along with many other interesting things, on my TODO list for Christmas break.
Classes are finally out for the semester. Exams are over. I can finally get back to doing things I enjoy.
Since involving myself in Alpha/Linux by creating the Alpha Linux Wiki I've found out there are quite a few pressing things to be done. Firstly, we can't use recent Xservers. On the Samsung UP1xxx motherboards, the only Alpha motherboards with AGP slots (outside of EV7/Marvel servers), we can't even operate at AGP speeds. I'd love to be able to fix these myself, but I'm not knowledgeable about Linux Kernel programming. I'm therefore forced to pester kernel developers into finding a solution.
A possible work-around for the first problem is to hack libpciaccess to access /dev/mem directly, essentially doing what older Xservers do. I feel like I may, with enough help from knowledgeable developers, be able to do this myself.
On another front, ever since Compaq stopped providing Java for Alpha/Linux we've done without. This isn't so bad you may think, but the next time you chose between Azureus and Transmission for your BitTorrent client, realize we don't get a choice. Other programs taken for granted on x86[-64] are unavailable to Alpha users. OpenOffice is a great example.
Maybe Red Hat's IcedTea project can bring Java back to Alpha/Linux users. In the next month, I intend to find out.
I used to maintain a guide to using Intel's C Compiler with Portage on the Gentoo Wiki, but ever since they've lost their database, I've been reluctant to continue work on it. Why should I write content for your site and help you generate ad revenue, especially when you can't even make backups of my work?
Fortunately, there is a static archived copy available. I plan to transplant it onto my site where I can make sure that it is going to benefit the Gentoo community.
It looks like my list thus far is
- Fix/Work around kernel bugs 10893 and 12127 one way or another
- Determine if IcedTea can bring Java back to Alpha/Linux
- Update Intel C Compiler guide and transplant to website
- Snap some pictures and make some web pages for my other interesting computers
Lastly, I've picked up some interesting computers recently to compliment my AlphaServer DS20L. These deserve a place on my website as well, so I'm creating a computers section. Check back soon for information on my HP J6700 PA-RISC workstation and my Samsung UP1500 Alpha system.
Software Engineering is not Computer Science
When I came to college two years ago, I intended to major in Computer Science. I looked forward to learning and being around people who shared my interest in computers. As I quickly found out, (1) there weren't any people here who shared my interest or even anyone who could speak the same language, and (2) the little bit of learning I would be doing in my computer science classes wasn't interesting to me at all. By the end of my first year, after attempting to discuss my feelings (read: disappointments) about the computer science curriculum and one professor specifically with the head of the department, I realized it wasn't going to change anything. If I wanted a computer science degree, I would sit in boring classes, be treated as if I weren't competent enough to possibly know how to program, and I would have to do my assignments in Ada. After a year searching for a silver lining around the Computer Science department, I switched to Physics -- which may have been the best decision possible if I wanted to do anything interesting with computers.
Initially, I entered college as a Pre-engineering major with the intention of later going to an Engineering school for a Computer Engineering degree. I took the same Physics classes as Physics majors, the same Computer Science classes as Computer Science majors, and the same (if not harder) Math classes as Math majors.
I knew from first class sign-up day that the Computer Science faculty expected all incoming students to have no programming experience, and moreover didn't care one bit if you did have any. Normally, you find someone with common interests, in this case programming, and you will talk to them about the common interest. Here, they treated me as if I was a know-nothing outsider.
My computer generated course schedule didn't include the introductory computer science class, which is the prerequisite of all higher level computer science courses. Not taking it meant waiting a full year to take any other computer science classes. It was entitled
CSC 120 - INTRODUCTION TO THE COMPUTING SCIENCES
It sounded silly, and after reading the course description out of the catalogue, I decided it was: binary arithmetic, how a computer works, and the use of editors and linkers in programming. Yes, editors and linkers. As if they are somehow closely related.
Unfortunately, it conflicted with my schedule entirely. Adding it would require that I drop and find new times to take two other classes.
I attempted to find a way out of taking this class, so I introduced myself to the head of the Computer Science department. I told him that I knew a few programming languages already (at this point, C, PHP, and x86 assembly) and asked if there was any way I could avoid taking this class but still be able to take higher level courses. He replied that he'd give me the final exam and that if I passed, I'd get credit. "OK" I said, "that sounds great." He got a strange look on his face and paused thoughtfully for a moment. He had been trying to call a bluff that wasn't there. He quickly withdrew the offer when he realized I was serious.
I was forced to rearrange my entire schedule before I'd even set foot in class to accommodate this entirely useless class. In this two-hour class, we literally spent eight class periods on binary numbers. It was a thorough waste of my time, and the frustrating part was that wasn't even the slightest acknowledgment from the professor. To him, I was just another idiot who couldn't comprehend zeros and ones. On top of that, there were no other students who felt like I did (To everyone else, this stuff was magic). The final question on the final exam which was the hardest from the entire class was an assignment to write code to add all the even numbers from 1 to 1000. I answered in x86 assembly.
Similar episodes occurred throughout the next two years. I also began to realize that the program wasn't Computer Science but rather Software Engineering. Learning to write fault tolerant, rock solid business applications in Ada, while useful, isn't interesting to the aspiring hardware engineer.
By the end of my freshman year I decided it would be a better use of my time and my parent's money to major in Physics. After all, in the same time it would take to complete the Pre-engineering and Computer Engineering degrees, I could complete a BS in Physics and a Masters of Computer Engineering.
I've been a Physics major for a year now, while still retaining a minor in computer science. In contrast to Computer Science, the Physics professors are helpful and responsive, treat students as intelligent creatures (even if they aren't), and are understanding if there's a course scheduling conflict, which mostly are due to, you guessed it, the Computer Science department not thinking of Physics and upper level Math students.
Best of all, I recently learned that one of my Physics professors has quite an interest in DEC hardware, including Alphas. He's even nice enough to find a cabinet to house my noisy AlphaServer DS20L in the Physics lab in the Science building.
Licensing Prevents Old Code From Being Freed
As previously reported, it was possible that Compaq's long dead suite of compilers and libraries optimized for the Alpha processor may be released to the Linux community. With hand written and highly optimized code in hand, Alpha developers could improve integral software such as gcc and glibc. Unfortunately, it does not appear that the release of this code will be possible due to licensing issues.
Linda Knippers of HP replied to my follow-up email today and told me that due to a couple things, it would be very difficult to release the Alpha tools so that they would be of any use to Linux developers. Firstly, some of the code in the compiler suite is encumbered by a MIPS license. I can only speculate that this goes back to the days of the MIPS-powered DECstation. With licensing comes lawyers, and we know how expensive they can be. It's just not worth HP's time and money to figure out how to free this code, especially for little or no gain on their part.
Secondly, the compilers are written in BLISS. Yes. BLISS. Even if the code were freely available, it would be in a language virtually no one is familiar with. As an side note, BLISS was developed at Carnegie Mellon University, the same place that developed the Mach kernel upon which Digital's/Compaq's/HP's Tru64 is based.
On top of all this, it appears to the current HP developers that all the Alpha tools for Linux were built on OpenVMS, making it ever more difficult for Linux developers to build the code assuming they could (1) find a way around the licensing issues, and (2) find a BLISS compiler.
Long story short, it doesn't appear that Compaq's Alpha tools will ever be released. Rest in peace, proprietary code.
I'm unsure if Alpha optimized libraries such as libots or libcpml contain license encumbered code. I will certainly make an attempt to find out. If they do not, there may still be a chance that HP will release their source codes.
Alpha Linux's New Wiki Unveiled
When I bought a DS20L from eBay, I struggled to find helpful information. I sifted through Google search results, searched HP's website, read hundreds of posts on mailing lists, looked at Linux and BSD release notes, and searched everywhere I could think of. In the process, the one thing I discovered was that there was not a definitive spot for information on Alpha based computers, Alpha/Linux support, SRM versions, Alpha assembly and optimization, or Alpha software. Hopefully this new Alpha Linux Wiki will be that definitive spot.
I have been working behind the scenes with AlphaLinux.org's Peter Petrakis for the last two to three months to create a wiki to house the wealth of knowledge about the aforementioned topics in a central location. As you can see by the TODO page, there is quite a bit of content to be created. The wiki is in place, and I have written only a small fraction of what is needed. This is where we need you, the Alpha enthusiast, to add content and help make the wiki grow.
There are some things that I cannot add to the wiki even with an immense amount of research. In particular:
- Pictures of Alpha hardware: Motherboards, CPUs, RAM, Cases, Full Systems, and any other Strange parts
- Difficult to find SRM versions. I hope to build some sort of archive to store all available versions of SRM (maybe ARC too?)
- Documentation. Do you have a document describing the internal workings of X piece of hardware?
- Assembly programming examples. Examples describing the usage of various instructions, concepts, or optimization techniques.
- Important Alpha related bugs. Particularly nasty bugs you can't wait to see squashed should be posted on the Bugs to watch page.
- Alpha related programming projects. Alpha specific code needed for a project? Post it to the TODO page.
I sincerely hope that the Alpha community finds this resource helpful and makes good use of it.
On a related note, as many Alpha users know, this is the first time that AlphaLinux.org has been updated in years. We hope to change this by adding a forum and migrating the main site to a content management system. Peter Petrakis would like to use a Ruby based CMS, and I have no preference. If you have any suggestions, please let me know. Also, if you have suggestions of ideas for other ways to improve AlphaLinux.org I'm all ears.
Radeon X1550 in an SGI O2?
In a thread on the SGI Enthusiast site, Nekochan.net, about Linux compatibility with SGI's MIPS based line of workstations, a user, tillin9, suggested the possibility of installing modern, off the shelf graphics cards in the SGI O2 under Linux. The O2 is equipped with a single PCI slot for expansion, so physically installing a new graphics card is no problem. Unfortunately, graphics cards require special initialization code, stored in the card's ROM, to be run at boot time. Since the Radeon's initialization routine has to be able to execute on the processor architecture in the computer in which it's installed, different code is required for x86, PowerPC, PA-RISC, SPARC, and MIPS. Since there weren't any PCI Radeon's made for MIPS powered workstations, surely ten years later, a modern Radeon would never work in an old SGI workstation...
Linux support for SGI's MIPS systems isn't on par with other architectures such as AMD64 or even Alpha currently, mainly due to the lack of man power and programming documentation. For instance, SGI has never released any programming documentation on their IP35 line of workstations which includes the Fuel and Tezro. On top of this, there's the problem of being unable to initialize the Radeon. Given this information, I incorrectly thought this meant there was no chance of installing a PCI Radeon in an old O2.
tillin9 seemed to mention that the inclusion of Radeon kernel modesetting would alleviate the problem of initializing the card. I was skeptical, so I asked around on the #dri-devel and #xorg-devel channels on Freenode about the status of the Radeon kernel modesetting code. Davie Airlie of Red Hat, one of the developers responsible for R500 support among many other things, responded quickly.
<airlied> mattst88: we haven't got radeon modeseting written yet..
<airlied> it might make .28, but it more likely will be Fedora first.
<airlied> I'm writing it as fast as I can.
So, the code's not done. It is obviously a high priority from his response. I've never seen a developer say anything similar to I'm writing it as fast as I can. Hopefully it'll be included in the kernel for the 2.6.28 release which should be about 6 months away. If not, it should be included in 2.6.29 a few months later.
Now, this code isn't being written in order to allow alternative architecture enthusiasts to use nice 3D graphics cards in SGI workstations. It certainly would be a great side-effect though. Again, I asked on the appropriate IRC channels. Alex Deucher of AMD, one of the main developers of X.org's xf86-video-ati driver responded quickly to my query.
<mattst88> will radeon kernel modesetting allow the usage of a x86 PCI radeon in a sparc, hppa, or mips box even without a special ROM?
<agd5f> mattst88: it should
What an excellent unintended benefit of Radeon kernel modesetting. I mailed the xorg mailing list just to be sure. From this, Alex Deucher responded to me again and clarified. In short:
- If the Radeon has AtomBIOS available, the card will be initialized by AtomBIOS (>= R400)
- If the Radeon doesn't have AtomBIOS, the card will be initialized by parsing initialization tables in the card's BIOS (<=R300)
- If the card isn't a Radeon, either an x86 emulator will be required to run the card's initialization routine, the driver will need to bang the registers to initialize it, or the card will need to provide a system similar to AtomBIOS
This feature, whose main purpose is to remove an unnecessary obstacle and provide a flicker-free boot up, will also allow many users of SPARC, PA-RISC, and MIPS computers to enjoy the features provided by a modern Radeon graphics card.
To tillin9: I'm sorry for doubting you. Thanks a lot for bringing the possibility of a Radeon X1550 equipped SGI O2 workstation to my attention.