Almost 12 years have passed since the TRON Project began. The project is making progress step by step. It also depends on how you look at it, but to us, we are pushing ahead to the maximum extent on things that are possible. To put it modestly, things are moving ahead gradually, but on our part, we think in terms that we were able to advance another step.
Generally speaking, we are engaged in many subprojects, and there have been various complications. At present, the main projects that are under way are ITRON, CTRON, BTRON; and then there is the question of how do you make TAD aiming at the realization of the HMI (human/machine interface) and the HFDS (Highly Functional Distributed System) as infrastructure.
Since I believe the readers of TRONWARE are most interested in BTRON, I think it would be best to talk about this in detail; ITRON and CTRON could be viewed as steadily widening their [base of] users, as can be learned if one looks at the "State of the Subprojects" in this special issue.
If we talk about ITRON, according to a certain U.S. research firm, ITRON is within the top five among operating systems for embedded civilian applications, and it estimates that there are about 500 million copies in circulation. Thus there is no doubt that ITRON is slowly but surely widening its market. This is something that is a result of untiring efforts centering on those of the ITRON Technical Committee. From roughly the point in time ITRON surpassed 50% market share for embedded civilian applications in Japan, activities to spread ITRON overseas have come to be vigorously promoted; we are about to turn to strong overseas development by doing such things as carrying out CI activities and the like based on the "We Support ITRON" [branding] mark (Fig.1), which corresponds to [the Japanese branding mark] "ITRON shiyoo-wo sapootoshite imasu;" actively holding seminars at the Embedded Systems Conference in the U.S.; and actively holding a series of seminars in Asia--China, Korea, and so on. The specification also is being constantly revised; I wonder if we aren't slowly beginning to realize that ITRON is being used in the world.
That's right. Continuing these activities for a long time is the winning formula; I believe we have satisfactorily placed ITRON in a phase of activities for it to spread in a stable manner.
Applications for switching exchanges where CTRON is used for communications control are not things that everyone uses, rather they are limited to the telecommunications industry. However, CTRON has already attained a position from which it won't be budged, and it is being used as a standard OS. This is the situation in the world of switching exchanges that was closed up to now; in order to spread the outstanding features of CTRON further, functionality is being strengthened for Internet server use, as Oki Electric is doing, so that we can further broaden the application range. Because the "C" in CTRON stands for Communication and Central, I think effort will also be put into this Central [part] in the future, in other words, server applications.
We are actively advertising the fact that CTRON also is an open architecture, and we have held a micro-CTRON contest. For this, we made public the kernel specification, which is a subset of CTRON; we did this with the aim of promoting free software based on this. We made reference of the fact that in the case of ITRON, the fact that there was a source program for reference use called ItIs, which the Sakamura Laboratory at the University of Tokyo has actively made public, played a role in spreading [ITRON]. The micro-CTRON contest, which was carried out to leave the impression that anyone can create it and anyone can use it, drew a great response. On top of that, the micro-CTRON that won the prize has been made widely available to the public via the Internet. I believe that slow but sure activities of this type will raise interest in CTRON.
Concerning the chip, in the real world, many of the Mitsubishi Electric Gmicro/100s, for example, are used in car navigation systems and so on. The Gmicro/300 and the Gmicro/500 are used in CTRON machines, and thus are supporting the communications infrastructure. The Mitsubishi Electric M16, which is a subset of the Gmicro/100, has attained corresponding production numbers and has obtained considerable success as an embedded MCU.
There are definitely other chips also, such as the [Hitachi] H32 and so on. Just that we had an influence on the computer architecture of Japanese microprocessors is a fact, and we also aimed at contributing to the training of people. Originally, we were aiming at incorporating the chip into personal computers and workstations, but regrettably this was entered on the U.S.'s list of trade barriers and came to be taken up as a candidate [for unilateral trade sanctions by the U.S.] under the Super 301 clause. We encountered numerous political obstacles, and so it did not come about that the chip was actively used for personal computer applications. But in the sense that it pushed technology forward, I believe that the chip played a satisfactory role. Since it will sound like an excuse, I don't want to talk about it too much, but in the processor business since you can't get anything done if you don't get the agreement of a lot of people, the chip architecture doesn't necessarily equal what I wanted to do. This is something you could understand if you were a person involved. Why the architecture turned out like that is a long story that I could write a book about. Since this story is interesting also as architecture, I think it would be good to publish it in the future.
Recently, since ASICs (application-specific integrated circuits) and silicon compiler technology are advancing, we are not putting all our weight into developing a microprocessor chip aimed at mass production; we have slightly changed our method of doing things. In my laboratory we have already finished writing the entire instruction set for the TRON chip with VHDL (VHISC [Very High Speed Integrated Circuits] Hardware Description Language). We are now at the point of thinking how to go about developing an problem-adapted-type LSI in the future. Also, we are interested in the so-called intelligent RAM, which is a CPU and a DRAM stored on a single chip and on which research is being carried out at various organs recently. Of course, we haven't lost our desire to develop a new chip. Since the things we are moving ahead on at present cover a variety of topics, it might be best to say that we are going to rest for a while regarding LSIs, but this in no way means that we are going to stop altogether with things as they stand, so I'd like you to look forward [to what we do in the future].
This is a thing called the micro-ITRON bus. In order to bring the concept of the HFDS closer to reality, we are interested in a network for control use that possesses very many nodes. It's already written down in "The Present State and Outlook for the ITRON Subproject" (on page 40 of TRONWARE Vol.42), and there's also a paper that's been published. At present, we have finished a simulation of a small serial bus with high real-time performance, and we are on the point of entering into trial manufacture. In the TRON Project as it stands now, we think that it is more important to fabricate a control chip rather than fabricating a microprocessor. In comparison to the past, I think the hows and whys of the instruction set have become less important. When the CPU and the RAM have been integrated onto one chip as with an intelligent RAM, if we look with long-term vision at the argument of what do we do one layer above in the architectural hierarchy at the OS layer or at the network layer, the processor ought to be viewed in macro terms as a system building block, and this is for the reason that we can no longer definitely say that the opening between the hardware and the software is necessarily the instruction set architecture (ISP).
Right. Just as in TRON, the protocol is the single important thing in the age of the HFDS. If we view things in terms of macros, then the modeling of the handling of messages between objects becomes possible. In an age when that type of higher layer interface is the problem, the instruction set no longer becomes the object of discussion.
You're exactly right. There has been great progress concerning this. Our HMI specification has drawn attention overseas also, and there are many requests [from people] saying they would like it. There was also a recommendation from the IEEE Computer Society as to the form in which to respond to these [requests], and so the IEEE Computer Society is going to put out the English version. We are now moving ahead with work to make revisions for that purpose. In Japan, the second edition (Shinpan toron hyu--man intafue--su hyoojun handobukku, published by Personal Media) has already appeared, but it is still not understood. I think that the necessity of aiming at a computer that is easier for humans to use and standardizing rules for its use will eventually come to be understood.
The BTRON project is the one I worry about the most; as I have previously insisted, [BTRON] is suitable for things that are light, small, compact and cute. In order to realize that, Seiko Instruments and Personal Media have jointly developed it. It looks like this will be marketed for enterprises as the BrainPad TiPO from Seiko Instruments (Fig. 2), and in the general market as electronic stationery from Personal Media; it was an uphill battle to get to the point where this type of item made its appearance.
They loaded the micro-BTRON-specification OS called B-right onto it; it runs 50 hours on two penlight batteries. Given that BTRON has come to fit completely on the palm of your hand, I wonder if quite an interesting thing hasn't come into existence.
That's right. [Microsoft Corp.'s] Windows 95 and [Apple Computer Inc.'s] Power Macintosh OSs of late have continued to become bloated; taking that there was a distinction between personal computers and workstations, personal computers have come to eat at the workstation market. This is like a repetition of the of the situation in which workstations have eaten away at the mainframe market; it's exactly the law of the jungle. I think going on to smaller things also is important as another principle current. When I look at PDAs (personal digital assistants) of the present, I think that rather than small things eating into the personal computer market, it would be better if they went down below from vicinity of personal computers.
If you ask what this means, from before in things such as certain electronic memo pads, there were limits and there was no thought of an operating system, application functions oriented toward a purpose were directly written down in machine language, and they came to be specialized into, for example, electronic memo pads, but now I think we're coming to limits of this way of doing things. If you look at the BrainPad you'll understand; although it's the size of a pad, its performance is above that of personal computers of a decade ago. This is the flow of the times. Personal computer OSs also have taken on large-scale OS functions and have become more bloated than UNIX and the like. The structure of the computer at present is a finished form in which there's a processor, and in which there's I/O, and in which on top of those there's an OS. If we look at it in macro terms, other methods for seizing on it, such as object oriented, messages models, etc., are also possible, but as for the minimal unit of the processor, I think that it will be based on the von Neumann model in the future also. Also, I wonder if [examples of] directly writing applications without an OS won't become fewer in the future.
In short, when applications become bloated, in order to raise productivity you need a reliable development environment, and in order to connect to a network an OS that responds promptly has to be prepared; that's because in the sense that "less haste makes for greater speed" [development] will probably go faster.
This BrainPad TiPO of Seiko Instruments is primarily intended for sale as a terminal for business use; it will probably be used as a [handheld] terminal in restaurants and [as a portable computing device for] use by traveling insurance agents; in contrast to the fact that applications [for this type of device] have been written in assembly language up to now, C language can be used perfectly when you use BTRON, and by combining this with MicroScript, it can be expected that application development will be possible in a very short period of time, and, in fact, that's the story that I've heard. In business applications, customizing for each customer is important, thus it is very important to provide a development environment with a high degree of flexibility through the combination of a MicroScript-type language and C language, and then making the OS into a microkernel type so that it is possible to organize in a manner in which the necessary modules can be selected. In other words, making it possible to fine tune for a particular application. micro-BTRON is actually made up like that, and let me add that I think an easy-to-understand PDA has been made through the provision of powerful rules of the type that are applied throughout the entire application in the manner laid down in TRON Human Machine Interface Standard Handbook in order to provide a seamless GUI for users.
For one, [there'll be] a lot of fussing over cooperation between mobile [computers] and the network. I think the cooperative operation of things that possess local data and file servers is very important. Because there can't be a restriction that you always have to be connected to the network, how you do the functions that obtain the cooperation is important. It becomes important to deal with such questions as how do you obtain only the necessary portions [of data] even in cases when it is impossible to obtain everything, how do you transmit only the anomalies, how do you collect together the untransmitted portions [of data] later and send them, and so on. Real-time mail is also important. This is a function that utilizes wireless, receives mail in real time through automatic startup, and informs the user; I think we have to move forward on implementing this type of function.
Concerning the Internet, I think the important thing is the intranet. When there are a lot of computers in a company, how any computer becomes your environment, how security is managed, how a local disk can be utilized as cache, and so on, are important. Also, when one wants to utilize high-capacity data such as high-definition image data immediately after startup, a function that does advanced staging of the necessary documents when the network is open through reservation will become necessary. Later, distributed cooperation of local processing and server processing will probably also be required.
I believe the real object/virtual object model is even now the most important concept among the concepts of the BTRON [architecture]. The real object/virtual object model goes beyond affinity with the WWW of the Internet; when a virtual object points to another computer, I believe it's even better, and so I'm thinking about expanding the meaning of the virtual object. The virtual object becomes a WWW browser, and this has already been realized. When a virtual object points to a cell in a table, when a virtual object points to the search results of a database, when the contents that a virtual object points to can be operated upon, it's a freer type of virtual object. It is possible to think of all sorts of interesting things, for example, as a CAD part, or when a virtual object is made into an object and there is inheritance and succession, or when there's cooperation between CAD and a database. The possibilities that the real object/virtual object hold are great to start with. I think I would like to like to actually prove that [BTRON] can become an even more outstanding thing by developing BTRON into a new network OS. We are at the point of entering a phase in which we will actually implement this. At the extension of this is the HFDS; a future-type computer architecture in which functions are distributed through combining distributed processing utilizing idle computers and agents on networks is now coming into view.
Since I touched on this the last time, I won't talk about it much this time, but due to the fact that we view characters as the most important thing in the BTRON project at present, we are paying a lot of attention to them. Currently, between the TRON Project and the Faculty of Literature at the University of Tokyo, very good, the best cooperative work is moving forward; at the University of Tokyo, furthermore, we have decided to produce by ourselves even a new kanji font called Todai Mincho [Tokyo University Mincho]. Activities aimed at producing a true multilingual computer by collecting all the characters of the world (Fig. 3) will of course continue in the future, but first we intend to go ahead and scrupulously do only kanji, thus we are making efforts aimed at making it possible to use 100,000 kanji on BTRON.
We have already finished implementing TrueType in BTRON3, and since we are burning with the ambition to output characters cleanly by paying thorough attention to gray scale fonts, proportional spacing, cunning, etc., I hope you will look forward [to what we do]. If I might add, from the viewpoint of EnableWare, we are also interested in being able to read correctly kanji that have been input, and thus we are about to add a study also on how to create a kanji dictionary inside the OS.
I wonder if 1996 wasn't a demarcating year in history of the computer. It is the year that is the 50th year from 1946, when the world's first all electronic computer, ENIAC, went into operation, and strangely, it's also the year that is the 25th year from 1971, when the world's first microprocessor, the Intel 4004, was born. During the lapsing of 50 years, [the number of] deceased has increased; Seymour Cray, who was praised as the father of the supercomputer, passed away in a traffic accident this October, and last year codeveloper of ENIAC J. Presper Eckert, Jr., and John V. Atanasoff, who is said to have developed a computer earlier than ENIAC, passed away.
Incidentally, 27 years have passed since UNIX went into operation on a PDP-7 in 1969, and for the Internet too 27 years have also passed since [its predecessor] ARPANET went on line. However, only 12 years have elapsed since the TRON Project began in 1984. An OS or a computer architecture is a [type of] thinking; it has a feeling like vintage wine. If you don't ripen it for a long time, it's not something that's fit to drink, in other words, it can't be used. There are many wines that can taste delicious after 10 years, even though they are ones that were not made during a bumper year, I wonder if we can't say a computer project is exactly the same as this. The origin of the UNIX project goes all the way back to the Multics project at MIT. It was an advanced and ambitious attempt, but because it didn't fit the hardware architecture of the time, there weren't many voices that could be heard saying it was a success. At Bell Labs, after it was made simple and compact by taking out the complexity in which it went from multi to "uni" and then was loaded onto a DEC PDP series [minicomputer] and made public, it spread gradually, and after the Berkeley release that supports TCP/IP was developed at the University of California at Berkeley, it came to establish a firm position as the standard OS for the Internet.
As for the TRON Project, we can say it's still [just] 12 years, and since it's a project that has continued for more than 10 years, the level of ripeness has slowly increased and the project has moved in a good direction. It would be nice if technology projects could always produce new results, but things don't necessarily go like that. I believe it comes down to continuing with unflagging efforts that stretch over a long period of time, in other words, [the saying that there is no success] in scholarship without [walking down] the royal road [to success]; thus continuing over a long time is important. Now, we are just coming to the point where new results can be produced at the end of long efforts. Anticipating your continuing support in the future also, I hope I will be able to respond to it and pull the project along.
The above interview with TRON Project Leader Dr. Ken Sakamura appeared on pages 32-39 in Vol. 42 of TRONWARE to mark the occasion of the 13th TRON Project International Symposium, which was held in Tokyo in the first week of December 1996. It was translated and loaded onto this web page with the permission of Personal Media Corporation.
Copyright © 1996 Personal Media Corporation
Copyright © 1997 Sakamura Laboratory, University Museum, University of Tokyo