SUN SPARC boxes use a IP address system for their switch cross bar architecture. It's a very interesting idea. I wonder how much benefit there is. But it would seem that the UltraSPARC T1 with 32 threads will increase the need for this espcially in a multi-processor system
--- "James G. Sack (jim)" <[EMAIL PROTECTED]> wrote: > boblq wrote: > > This is for Stewart's benefit. > > > > So he can laugh at me. Well again. > > > > I offered to do some prototype work for a friend > > and colleague. He want some XML to native data > > format conversion for an application he has. I > said > > sounds good to me. I needed the money anyway so > > I was ready to roll. Begging consultants don't > always > > get to pick and choose and the end of the year is > > always a hard time so now is the time to get the > > gigs going. > > > > So he sends me the code. > > > > He wrote this stuff in Fortran over 25 years ago. > It has > > been tested and audited and through all kinds of > expensive > > QC programs that insure it produces correct output > ... > > this makes it "sacred" code. They only audit and > test the > > results though. We are not talking about looking > at the > > code. So a gazillion dollars has been spent to > make sure > > this code generates correct results. Nothing has > really been > > spent on code maintenance. > > > > Along the way it has been from Fortran through > RATFOR, > > and then through a RATFOR to C convertor, which > emulates > > Fortran IO using curses, a subsystem that I have > always > > thought was aptly named. > > > > All of this for what is a command line > interpreter. The underlying > > data structures are UDP packets with the packet > contents > > containing both data and operators on that data. > It has its > > own virtual memory manager built in. It is sort of > a packet based > > distributed computing system. > > > > There is just one small problem ... The C code > compiles but > > no longer runs. Somewhere along the way a short > while back > > the code broke and no one can fix it. Audits > galore they have > > but no real backups. He,he. It is only 40,000 > lines but has over 800 > > gotos as a result of the way the converter deals > with various > > Fortran constructs. > > > > There is essentially no documentation except the > code. > > > > So I need to get it running. > > > > I really don't know WTF it does. It did some kind > of economic > > calculations for the Norweian government not so > long ago. > > The core engine is/was capable of all kinds of > things. > > > > One of the reasons I got involved was because the > guy who > > first wrote it is very bright and I was intrigued > to see what > > a packet based distributed computing system might > look like. > > > > You would have to see this code to believe just > how bad > > it can get. There is nothing quite like a code > translator to > > give you (lots of) code that is damn near > impossible to > > read. > > > > I won't go further but I wanted Stewart to know > that sometimes > > even a prototyper like me gets hoisted on his own > petard and > > must face the demons of maintenance. > > > > So it goes, > > > > BobLQ > > > > Oh yeh, I almost forgot, the user commands and > responses > > are in Norwegian, not my best language ;( But hey, > that is > > only about thirty words how hard can that be. > > > > good story! > > > BTW.. > > I can put you in touch with a local Norwegian EE who > could probably > verify your translations/interpretations of the > commands or other such > stuff you run across. > > And also (just curious): are you going to do some > heavy duty xslt > processing to deal with the xml-to-X work? > > ..jim. > > > -- > [email protected] > http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list > -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
