Jeff Fox to SVFIG 11/22/03
My first topic will be one of your favorites, keyboards. (short period of laughter) Lafar mentioned earlier a Forth system that used a Morse Code keyer for input and which used Morse Code output. Chuck continues to have new ideas about keyboards. A few months ago he seemed excited about the idea of having some colorforth keyboards made. When you use his colorforth you use a normal PC keyboard, but you only use 27 keys. They are in a quasi-Dvorak layout that changes their assignment from time to time and prompts you on screen most of the time what character is assigned to what key. But because there are many other keys on the PC keyboard sometimes your fingers slip off of the keys where they are suppose to rest and you touch type the wrong keys until you find the ones the you are suppose to use. At least I have had this experience. So I could make a colorforth keyboard by simply removing all but the 27 keys that are used. But it would be ugly. Chuck liked the idea of having someone make a nice looking, and colorful, keyboard with only the 27 keys used in colorforth.
Would this make colorforth more popular? Personally I doubt it. But perhaps colorforth users and collectors would want a funny PC keyboard with 27 keys that matched their colorforth environment. I guess I would like to have one and would enjoy using it, but I really don't think that there is much of an audience and I just don't see how it would be justified. And I really don't see it making colorforth more popular. But Chuck continues to rethink the keyboard issue as everything else.
I saw an interesting film this year that I thought was quite relavent to the kind of work we do. The name of the film was McLuhan's Wake. It is a very thought provoking film about the work of Marshal McLuhan and in particular about his work on the universal laws of media. I was thinking earlier today that considering the audience I am before most of you are old enough to remember Professor McLuhan. In fact I expect that most of you remember exactly where you were fourty years ago today; 11/22/63
McLuhan was not well understood at the time although he was quite a celebrity. He studied the effect of human media. One of the points for us here was the comment that 'We make our tools and after that our tools make us.' Every human media is some extension of us either physical or psychic. He detailed the history of the spoken word, the written word, the printed word and how each of them created and destroyed cultures. He detailed the emergence of electronic media in the human community and coined the phrase 'The Global Village.'
He tried to look forward to the effects of electronic media on us and our culture based on the first indications from radio, phones, television and computers. He foresaw the global networking of computers and the sorts of web searches that we do today and predicted what changes it would cast on our culture and on us. Looking back, which as he said is mostly all we can do, his work was amazingly accurate in predicting the sort of immersion in electronic media that pervades our culture today.
One of his early observations was that people were numbed to the most pervasive details of their environment and had the most difficulty even recognizing them. Today we are so much more heavily immersed and saturated in this that most people don't see it at all and don't think about it. But his main point was that recognizing the patterns before they are complete is the goal of the game. It is the only way to have any control before the patterns play out and it takes attention and effort. I really think that anyone deeply involved in implementing new technology and unleashing it on our culture really need to do some serious thinking about what they are doing and where it will lead. It is a responsibility we have. I know from personal experience that I had not really thought enough about the types of new technology that I helped develop before jumping into the process.
I found particular interest in McLuhan's Laws of Media, the laws that apply to all media irrespective of the media's content. They are something that apply to our work creating new electronic hardware and software. I think it might make an interest presentation in the future to examine in more detail these sorts of effects that new media are bound to have on the culture.
Last year I gave you a presentation on Alegra, Soeren's GUI that was written for Chuck's style of machineForth processors and their tiny video coprocessors. I told you about the way it cleverly used the video coprocessor as a Windowing accelerator allowing the CPU to do much less work in managing a layered multi-window desktop. I described how it worked and showed some of the code. I felt that it is a good example of how one could get a long list of GUI functions out of half of a K of code if it was cleverly written. It demonstrated again that writing megabytes of code to link to tens of megabytes of code is not the only way to do things like provide GUI access to applications.
This year he wrote a machineForth environement for the PC. It is much like colorforth since they are both based on the machineForth improved Forth virtual machine model. However it uses a classic style compiler and classic style command line interface that most Forth programmers are familiar with. This year he also wrote a number of programs in both machineForth and in Java to compare them. If you don't count the Java interpreter and only count the bytecode and compare it to the machineForth code you find that the machineForth versions of the applications were five to ten times smaller than the Java bytecode. He said that he made no particular effort to make the Forth code smaller and that he could have made it smaller if he had wanted to but since Java bytecode is often touted as being memory efficient he just wanted to see how it compared to reasonable machineForth.
His machineForth environment for the PC is not something that I would have thought of. It is interesting to see what other people come up with as their own creations. He makes his living programming cell phones in C. He told me how each team delivers their module and they schedule a full week to compile it. I found that funny because I have been told so many times in c.l.f that C compilers today are so fast that it is instantaneous and that no one cares about how long things take.
In fact I followed a lead from c.l.f about bugs in GCC to study some of the thousands of bugs documented in bugzilla. Amazing stuff. I thought the names of the catagories of some of the bugs were pretty funny in light of the claims in c.l.f about the instantaneous compiles. Under compile-time-hogs I found complaints about how a few lines of code could take hours to compile and how increasing a parameter in the code would result in exponential increases in compile time. The examples were only a few lines, not hundreds of thousands or millions of lines of C either.
The bugs under memory-hogs were entertaining too. For instance allocating stack frames larger than 2GB would cause errors and a nice example with a 4GB stack frame was given. Up to this point I had recoiled at the thought of megabyte sized stack frames in C, but multi-gigabyte stack frames? Well those folks sure have a different view of the world of computing than those of us who use Forth and see unneeded overhead in constructing even moderate stack frames when we have a nice parameter stack that is not entangled with a return stack.
I would like to comment that I have been pleased and somewhat suprised to see a growing community of colorforth users. People have created drivers for lots of other video cards, other floppy drivers and QWERTY keyboards. In addition to Chuck's stand-alone version and its variants people have ported versions to DOS and to Windows and to Linux. So there are versions that run on almost all PCs these days and it should help bring an end to some of the early complaints that people had that they could not get a version to run.
The mail list has been active from time to time and we have engaged in a number of colorforth chats in various chat rooms and in the UKFIG monthly chat session. The chats at UKFIG in particular have been quite delightful. No Forth haters or colorforth haters, just nice civilized discussions.
(From Alan in the audience) There is an interesting discussion going on now in comp.lang.forth about colorforth.
(I raised one eyebrowe and looked at the audience with skepticism. I had never seen any 'interesting' discussions of colorforth in comp.lang.forth as it seemed like a taboo subject there. But I thought now that we have a dozen or so colorforth authors and some colorforth users who regularly post to comp.lang.forth maybe things have changed there. It used to always invoke a lot of attacks and posting of missinformation by people who didn't want to hear about colorforth in comp.lang.forth.)
I replied that I would have to check it out. ;-)
I have had the pleasure this year of working with Chuck on a new project. I have been using colorforth and OKAD II to assist in the CAD work. I have also been involved with providing documenation and in answering potential business partners technical questions about the project. Using colorforth has been fun.
I thought about writing up some very simple pages about my first experiences using colorforth. Something like:
Using colorforth has been fun.
I am just a beginner at it.
Mostly I write in green. (compiled code)
Sometimes I write in yellow. (interpreted code)
Sometimes I write in white. (comments)
But I often have to change the things I write in white.
I have not created any pages like that but I thought that it might help convey the enjoyment of such a simple and easy to use environment. It stands in rather stark contrast to systems with thousands and thousands of hidden pull down menus and countless long involved processes of chasing buttons and sliders around and having to go through dozens and dozens of steps to things that are usually a key click away in this `Windows' environment.
When I first started using it I had funny thoughts go through my head. This Dvorak keyboard layout is wierd. I touch type very fast on a QWERTY layout and I wondered if training myself to use Dvorak would mess that up. But within minutes I found myself starting to think about where the key that I wanted was and watching my finger push down on it as if to tell my brain not to worry about it, it is right here in the most convienient place, right under this finger. As I used colorforth and navigated the programs in the OKAD II suite of programs I would notice that quite often they thing I wanted next was right there as if the system had anticipated my needs perfectly. Ah, custom software is nice.
I really think that retraining your reflexes is a very important thing. We humans like to think that our brain guides us by reason, but for the most part it is reflex and about all the brain can do is rationalize how clever it is to know how to do the right thing. But as the patterns get burned in the alternate circuits in our nervous system become weaker and the ones we use more become stronger. When we are young and learning new things we build new circuits but as we age and fall into habits we do less and less of that.
To keep the mind and body from aging far too quickly it really helps to consciously force yourself to do new things that conflict with old habits and which require building new networks. You have to try out new ideas and new ways of doing things. It helps to get your body to move in new ways also to get the brain to come up with new ideas. So trying something completely different, like colorforth, has been a quite delightful experience for me. I have heard similar reports from some of the other people with whom I have discussed it. It is hard to quantify why trying new things can feel so good.
I should say one thing good about comp.lang.forth. I was able to learn something there this year. I feel that I finally got a handle on ANS Forth. (pause for longer laugh than for the opening comment about Chuck's keyboard.)
I read the document years ago and I have to admit that it seemed to make no sense at all the first time. But after a large number of readings I thought I got it. Then I asked a lot of questions and I thought I got it. Then I implemented and ANS Forth with a list of extensions and I thought I got it. Then I ran the Hayes test suite on it and learned more and I thought I got it. Then I wrote ANS Forth applications and I thought I got it. Then I worked with other ANS Forth programmers and I thought I got it. Then I managed a team of a dozen Forth programmers and I thought I got it. And I read lots of postings in comp.lang.forth and asked questions and I thought I got it.
But for all of that there were certain things that I just could never get. They seemed like nothing more than the sort of advertizing that one sees on TV every day. This miracle scientific breakthrough is quarenteed to make you lose weight without ever dieting or sweating and change your life forever, make you rich, famous, you will get babes like these and will you never grow old or regret changing your life for the better. I mean there were always lots of claims like this for ANS Forth, I mean it seemed to me that so many things were about as believable as that. In particular the comment that I thought was the funniest was 'ANS Forth forbits nothing.'
I could never get anyone to discuss topics like ANS Forth without seeing nothing but pure denail. No, we can't discuss that subject, it is as simple as this, 'ANS Forth forbits nothing, period.'
I would wonder how anyone could possibly make a ridiculous statement like that. I would say, well look in front of me I have a document that is hundreds of pages thick and it is filled with hundreds or thousands of statements that read an ANS Forth system must ... and must not ... and shall ... and shall not ... and may ... and may not ... and an ANS Forth program must ... and must not ... and shall .... and shall not ... and may ... and may not ... .
Now every one of the statments is delineating what ANS Forth allows and what ANS Forth forbits. Even every statement of what it must do is an implicit statement that it forbits NOT doing something. Yet this subject could not be breached without getting the response 'ANS Forth forbids nothing.'
Perhaps they are using some odd definition for Forbid I thought. So I looked it up in a dictionary. 'Forbid: to prescribe behavior as from a position of authority. As in her mother forbids her from going out on weeknights.'
Ok, so the ANS Forth document and its owners and interpreters are absolutely prescribing behavior as from a posiition of authority. That is the dictionary definition of Forbid. And there are hundreds or thousands of such textbook examples in the document, how can anyone possibly say that 'ANS Forth forbids nothing?' Why when you ask such a simple and honest question do you never get any response in c.l.f and why do people then talk down to you as if you have never read the damn document or programmed in that damn dialect of Forth?
So I pressed on saying ok, let's talk about specific examples. I said ok, so here for instance is an example of some machineForth code that was cleverly written to fit and run in this environment. An almost perfect one to one match with the hardware and not unlike the countless examples that I have previously posted in comp.lang.forth showing how this dialect can usually easily beat ANS Forth regarding the size of the code expressed and the size of the code compiled. It is the kind of example that I have been posting for years and one which I just don't see as ANS Forth.
To begin with the 'IF' is non-destructive. It does not do what ANS Forth clearly states IF MUST do. It is clearly not ANS. And the next word has the same name as an ANS Forth word, but the behavior is slghtly different. And here it has auto-recursion because it is not SMUDGING its own name and making it invisible again compiling behavoir that is not ANS. And the definition has two semicolons because one acts like EXIT and it is no problem here, but ANS doesn't treat semicolons that way. This code is shorter source than the ANS version and compiles to less object code than any ANS Forth for other type of hardware that I have ever seen. If this is not a long list of things that are forbiden in ANS Forth what is it?
Well J. Thomas was the only person who was willing to discuss the subject without just dismissing it with the catch phrase 'ANS Forth forbids nothing' or by saying 'ANS Forth can do anything.' Excuse me?
What he explained to me, and others, was that apparently the reasoning was something like this: ANS Forth has facilites to permit construction of alternate wordlists that can have any behavior that you want. If you want to define an alternate wordlist where you duplicate many of the names of ANS Forth words but assign to them non-standard behavior you can do that. So one can created a machineForth compiler wordlist in ANS Forth and get that behavior that I described in the simple way that I imagined or in bizare ways that I had never imagined. Well sure, of course, that must be what these people have meant all this time. Well sure, of course I have done that myself, writing an ANS Forth cross compiler to produce machineForth target code from simple machineForth source code. I finally got a handle on the reasoning behind what seemed like bizzare and patently false statements to me like 'ANS Forth forbits NOTHING.'
So I asked several times, and of specific individuals if this is what people had meant and if ANYONE had any objections to Mr. Thomas's explanation. From the silence it seemed that I finally understood what they meant.
But then again, there was a second definition after the first definition of Forbid in the dictionary, as in 'Time and Space forbid further explanation here.'
I did not bring the subject up again in comp.lang.forth but I thought once again that it was very funny. My whole point had been after all that the reason for the non-ANS behavior was that the system that produced the code and the code itself fit into the problem space. This was tiny code for a tiny system where it fit perfectly and matched the hardware directly.
It was time and space that were 'forbiding' use of ANS Forth. The idea that one could start with an ANS Forth system that didn't fit in the first place, then add non-standard extensions to it to provide alternate behavior for IF or semicolon or for the compiling behavior prescribed by ANS Forth was certainly an idea that I had never considered because the examples I had given had included the constraint that it fit the problem space.
It became clear to me that what they were talking about was that if I attached a PC, a gigantic computer by comparison and ran ANS Forth on that and then duplicated the names of many standard words in a non-standard extension to ANS Forth and used it to program the system that I had been talking about then ANS Forth was not forbiding me from writing in a non-standard dialect after that.
But of course that was never what I had been thinking. I had been thinking that the Forth system should be a size as to allow it to fit perfectly into the problem space where ANS Forth was too big, let alone an ANS Forth with further non-standard behaviors to do what I was talking about. These people were talking about adding a second computer to the picture to use ANS Forth. Since I thought I had made it perfectly clear from the beginning that I was talking about more severely constrained environments than that from the beginning I could see that the other folks had been talking about something entirely different.
Now I would still debate whether time and space are doing the forbiding, or whether the extra space required by ANS Forth with further non-standard extensions as well as the extra time and effort to do it that way meant that time and space were doing the forbiding or whether it was the ANS Forth standard itself that forbid simply doing the simpler and smaller and easier thing that actually fit. It made me think that the statement that ANS Forth forbids nothing still is not a true statement, but at least I could understand the twisted context in which one could interpret it as true. I honestly seemed like such a twisted concept to me that that train of logic had simply never occured to me.
So I thanked Mr. Thomas in front of SVFIG for this patience in explaining the logic used behind the statement that just had never made any sense at all to me before that. I still doubted that anyone in comp.lang.forth had ever understood what I had been asking in the first place. But at least I felt that I got a handle on understand the statements made about ANS Forth a bit better.
There is good news and there is bad news. I won't tell you which parts are good and which parts are bad since I expect that many people will see them the opposite way that I do.
Unlike my work at my own company, UltraTechnology, when Chuck was working as a consultant and I was a client, and where I had almost complete control over what I was willing to make public (which proved to be a problem when I was at iTV) I am now in a postion where I have been asked to not make certain information public at this time.
That is pretty much the usual thing. My being able to be completely open and answer any and all questions about the development at UltraTechnology was a rather unusual situation. I still haven't decided whether making everything public was a good idea back then or not.
I thought that there were people who wanted to know and I thought that there were people who might benefit from the information. I never expected for people to claim that I was ever lying about things and I never ever expected to see the vile name calling and insults, the kill the messanger behavior, or to get death threats because I made information about Forth work public. So at least here I have an easier postion since I have been asked not to post the sort of real definitive technical details that have in the past provoked those sorts of responses.
If any of you have visited my website in the last year, http://www.ultratechnology.com/ you might have notices something conspicuous by its absence. For years I video taped Chuck's and some of the other presentations to SVFIG and posted them on the web in different formats. I often did transcriptions into HTML for those who could not access videos for various reasons. You may have noticed that I never posted the video of Chuck's presentation here last year. (2002) I was asked to delay posting it because Chuck revealed more details about some things than we really want to make public at this time.
(Chuck had sent an outline of new information about OKAD II that was 'neutral' in not revealing any proprietary information down to George for Forth Day this year, but George thought it was just a copy of his OKAD page on the web and he didn't bring it to the meeting. So I just spent a short amount of time on the subject covering some details of colorforth and OKAD II that I had brought in my notes.)
We are working with a team of people who's resumes are most impressive if not intimidating. Combined they have a huge portofolio of patents (myself excepted as I never filed any) and also an Emmy. I am working as Director of Software and on the VLSI CAD work. My background of working with Chuck on several projects since 90 is a good match to the work going on and I work well with Chuck.
I have also been acting as a technical consultant to potential business partners to answer their questions about our hardware and software. I have been doing some traveling on the road to some places that I would not have likely visted otherwise. Sometimes these people are a bit conservative compared to the culture here in Berkeley and to look a bit more conventional myself you might notice that I have more than foot less hair. It also made the travel easier and lots of places have much more extremes of weather than Berkeley so it was a lot more comfortable.
On some of these trips I brought along a little F21 computer and used it for doing presentations alongside similar presentations in powerpoint. I didn't go into the details of the Aha OS or desktop under the apps but rather just emphasised the details in the presentations. But it was also meant to show that the fourth generation Forth chips had been made and were real silicon not just theory. I would explain what were the limitations and bottlenecks in that generation of chip and who we attacked those limitations and solved those bottlenecks in the next generation design. We would also show the projections, made by OKAD II and other more conventional VLSI CAD software of the speed, size, and cost of the next generation of chips fabed in more modern processes.
I was amazed to learn about the achievements of some of the members of the team. It is also fun to see the state of the art engineering and packaging of some really nice consumer items from some of the potential corporate partners. The applications on the table are some things that I thought of only as dreams for fourty years. I was not aware of the devices that some of the team members had developed and was very impressed. We have some top experts from several fields. They have done some amazing stuff and are very excited about moving to the next step of custom silicon. Some of them have done stuff that has required a room full of workstations and some special expensive hardware or done second generations that were crate sized boxes filled with expensive (and very hot) FPGA technology and are very excited about moving to a custom VLSI platform where it will be absurdly tiny, low power, and very inexpensive to manufacture. Those working on the hardware are excited about it and about the dynamite apps.
Don't expect to see these chips on the open market and don't expect to see full information about them made public any time soon. If you are lucky you will be able to get them embedded in some consumer technology that I am sure you will want to have. But unlike iTV which planned to make the 4OS, Internet Appliance, and Forth scripting software open source after putting considerable hardware out into the field that is not the plan here. So unless you end up working professionaly on one of the development teams somewhere you won't get direct access to the hardware or software this time.
Speaking of that, this company has aquired access to the old iTV software. I am pleased about that because one always hates to see several years of your work being intentionally locked away on a shelf. I am not sure about the future of that software but since it is compatible with F21, and I had an agreement with iTV to license it for use on my chip it still interests me. I will let you know how that works out and if and when you might see it or get access to it.
Working with colorforth and OKAD II has been quite delightful. Whenever I visit Chuck the first thing that I do when I get home is to review VLSI design literature to be sure that I really understood some of the comments that Chuck made. Of course occasionaly I have no references to certain issues, especially ones that Chuck most recently discovered or uncovered.
Using colorforth has been fun and easy. It is most interesting to compare the operation of some of the commercial packages that we are using next to OKAD II. They both deal with the very complex problems of VLSI CAD but the user interfaces and internal representations of data are so different. Of course they have to be compatible in many ways, but not all.
As Chuck has told you OKAD II was reorganized from OKAD by taking what had been roadblocks in OKAD such as output to GDS II format for fab and used those limitations as levers in the design of OKAD II where he can take advantage of them. This is something that I observed Chuck doing years ago, that is when he rewrites and improves his software he takes the things that were bottlenecks in the last version and either avoids them or better yet uses them to his advantage.
The internal representation of the chip while working with a design is again hand tuned to get the most efficient use of memory possible. The machine I am using has only 128MB of RAM but because of the efficient representation of gates and the miniscule use of memory by the OS and the CAD programs themselves most of that 128MB is available for simualting chips. Chuck can do even more complex simulations of even bigger versions because he is running with 512MB.
All the application programs and the chip design itself is stored in Forth source code, colorforth to be specific. So of course that means that there are colorforth cross compilers for the simualted chips. (and many other colorforth programs that I listed yesterday in another thread in c.l.f.)
While I have done some CAD programming myself it was mostly simple things. And most of the programming I have done in colorforth and OKAD II is internally cross compiled into the simulated memory for the target chips. Sometimes I even felt a bit guilty for getting paid to write such trivial code, very simple and tiny Forth scripts in colorforth. But testing his harder than it might appear to people who haven't done it.
Chuck sometimes tells people that the chips run colorforth in hardware. I prefer to say that they run machineForth in hardware and that Chuck uses a colorforth compiler to generate the code and provide the colorful user interface. No complete colorforth has been run on the simulated chips. But since the object code of machineForth or colorforth are the same thing I am very comfortable with this environment.
When developing new hardware one has to run simulated test suites and I have written a lot of them. They start out as the most trivial Forth code possible. Chuck tends to just test new instructions as he implements them and then he moves on and I follow up with more extensive tests. I could show you the 600 trace virtual 2000 Mhz virtual osciloscope interface for the hardware simulator. You would not have any idea what you were looking at, but it would be colorful.
It runs very slowly on my machine. I think at one point I timed things and determined that it took about four minutes to simulate a nanosecond of code. It gives you a strange perspective. My machine is about nine times slower than Chuck's so I can see things that are not visible on Chuck's display because they go by too quickly. It reminds me of the comment that Chuck made a few years ago about the speed of light used to seem fast to him but now it didn't anymore. As I say it gives you a strange perspective.
Watching the pico-seconds tick by has given me the impression that pico-seconds are pretty slow. When I think that each click is a thousand femto-seconds that makes me think that femto-seconds still seem pretty fast to me. It reminds me how milliseconds seemed fast to me until I got my first personal computer in 75 but then microseconds still seemed fast. And how as the technology evolved that microseconds seemed slow and nanoseconds seemed fast. Now nanoseconds seem slow. The technology moves forward so fast that I had to go look up what was coming after femto-seconds, atto-seconds. There are a billion atto-seconds in a nano-second.
(That still seems fast to even on the fastest computer technology that I have seen in this custom Forth processor work. But we are still working with silicon so we are not implementing our designs with the 1.2 femto-second transistors the optical folks were working with. Maybe we will make that jump sometime since it has so many other advantages over using those big electrons.)
It is almost nice that I am not suppose to talk all of the things that we can do that make nanoseconds look big. I got so much damned flack for talking about interrupts or task switches in a few nano-seconds years ago with people who live with technology where these things take millions or billions of times longer. You know we really do live in a very different world with this stuff than the people using the old designs that are still so popular or other off-the-shelf stuff.
And the kind of programming that we is pretty much at the opposite end of the spectrum from the people who mostly program desktop systems. I am not just talking about the difference between say colorforth and OKAD II and the more conventional tools that we have licensed to us, after all that is still a mix of these ideas and constraints on the dreadful Pentium hardware. When we are thinking of the chips that run the stuff in native code at higher speed and with much less memory the style of programming is just quite different than say what desktop folks are used.
I sometimes think that it would be very funny to have a programming contest here at SVFIG, or on the Internet, that used this sort of environment as the posed problem. Something from the real world. Something that gives the flavor of how nicely Forth fits the problem. But I would really be suprised if anyone in the outside world would be willing to take up such a challange.
For instance we might ask for something relatively trivial. Your assignment, should you accept it, is to write a program that will output 'Hello World' in some form of video and on the serial port and on the parallel port. Each form of output would be worth one point. One extra point for the display judged most esthetic. Here is the specification for the chip that we are getting back from fab today. Here is the specification for the test board, and here is how you will run your program on the simulator that we will provide.
Now the catch. Remember of course that we have never seen this actual chip yet, so you will not know whether the fab process worked as expected. We will be giving you a simulation of a chip from the corner of the die that didn't quite work exactly as we intended. We know that there are one or more bugs and exactly what those are but you don't. Your job is to write and run your Hello World program and in the process figure out what works and what doesn't work on the chip to provide that information to the hardware designers to make it possible for them to fix those problems. So you will get a bonus point for every bug that you correctly find in the hardware and describe accurately. We will not tell you ahead of time how many potential bonus points you may get.
You are free to use any computer to develop your programs and any language or OS, work in teams or whatever. You have this long. Now go.
Now this kind of real world programming challange would emphasis just how different this kind of programming is from the sort of programming that many people do regularly. Suddenly a trivial Hello World program does not look quite so trivial.
If you trust the hardware that you are using, and trust the OS that you are using and trust the compiler that you are using and trust the code that you write the only bugs that you have to worry about are the ones in your own code. Here you are unlikely to have support for this environment already built into your computer. But everyone, except the people running the programming contest, would start out even.
If you think that writing a machine description for this machine for GCC for this machine and re-using a Hello World program that you already have written in C, have at it. If you want to do it with Java, or Perl, or your own Forth or whatever, have at it.
Anyway as I said, this has always struck me as a funny idea along the programming challange lines.
As for the specifics of the chip, you already had Chuck's presentation last year and I am not authorized to tell you about what has been updated or changed on the design. You aready know more than has been public released outside of SVFIG.
(Question from the audience) 'Why is hardware simulation so slow? Is it complicated?'
Well the equations used in OKAD II are simpler and faster than the ones in the software that uses the Spice models. But size of the problem space and the fact that you are calculating the voltage and current and temperature at every junction on the chip for these tiny increments of time means that it is very computationally demanding.
We can simulate circuits with the Spice tools but those run much more slowly and we can only simulate a very tiny fraction of the chip since those tools just do not represent the details of the chip efficiently enough to be able to simulate very much. We can simulate small simple circuits extracted from the design with the Spice tools which is progress. I think we have much better people than we did at iTV. iTV had access to some very expensive VLSI tools, these are big complex programs or people couldn't charge and get hundreds of thousands of dollars for them. But back then they couldn't even simulate an oscilator or counter in Chuck's designs. They simply claimed that they could not possible run. Yet there were the real chips runnning as predicted by the OKAD simulator.
And my computer is only a 333Mhz Pentium II so it runs a lot slower than the 2.8G Pentium IV on the larger machines. Real hardware will be a delight because it will run a few hundred billion times faster than the simulations we can run on Pentium today.
(my suggestion for an SVFIG Logo a few years ago.)