Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!ucsd!tut.cis.ohio-state.edu!cs.utexas.edu!csd4.milw.wisc.edu!uxc.cso.uiuc.edu!uxc.cso.uiuc.edu!mcdurb!aglew
From: aglew@mcdurb.Urbana.Gould.COM
Newsgroups: comp.arch
Subject: Re: TRON (a little long)
Message-ID: <28200335@mcdurb>
Date: 25 Jun 89 16:23:00 GMT
References: <382@h.cs.wvu.wvnet.edu>
Lines: 98
Nf-ID: #R:h.cs.wvu.wvnet.edu:382:mcdurb:28200335:000:4959
Nf-From: mcdurb.Urbana.Gould.COM!aglew    Jun 25 11:23:00 1989


...TRON

(Note: I use the editorial mark ..> for paraphrasal or summary):

..> Jim Mooney (jdm@a.cs.wvu.wvnet.edu) asks why there is little
..> discussion of TRON in this newsgroup.

Probably mainly because few of us in the US know much about TRON;
because the details that we have seen, in conference proceedings
and survey articles (like those in IEEE Computer) make TRON sound 
like an anachronism; but mainly because we do not know enough to
properly discuss TRON.  I know that I don't - and I have been 
listening carefully for anything I can get about TRON (although, not 
reading Japanese (yet), I cannot listen all that well) - but then 
again, I haven't gone and actively sought information. Spoiled by the
rich information stream, perhaps.
    Having said that I do not know anything about TRON, apart from what
I have read in the American press (so I have seen the CISCy 
instruction set - so what?) I should probably shut up --- but I will
comment on some of the other comments on TRON,  and, in one instance
below (which I will flag by ****s) I will even make a brief
architectural comment.

Overall, the success of TRON is probably unrelated to the computer
architecture implied by the TRON standards (instruction set, etc.);
as in all computers, but especially here, success will be mainly 
determined by economic and organizational factors: (1) can millions
of TRON chips be produced at acceptable price/performance to compete
with other microprocessors (ranging from Z80s through embedded 
controller type micros like the ARM and my company's products, to the
top of the line workstation microa);  (2) will the many lines of TRON
software required be written quickly enough;   and (3) will TRON be 
an effective standard, ie. will the participating companies products
really be interchangeable?  
    I am most concerned about the last, as already the division into
ITRON, BTRON, and CTRON seems to fragment the TRON market; is there
a kernel TRON that is portable between all [IBC]TRONs, and are there
already any products in this kernel TRON? All the announcements I have
seen have been more of end-user products, than anything in this kernel.

And now I'll repeat one of my more annoying observations:
	In the 50s and 60s the British had all the good ideas in
computer architecture (microcode, virtual memory, etc.) but the 
Americans kept on building faster and faster machines, that were
architecturally behind the times, but succeeded by brute force
(and skillful circuit design and process).
	Now, in the 80s and 90s, the Americans have good ideas
in computer architecture (RISC, VLIW, etc.) but the Japanese are the
leaders in the basic implementation technologies (I hesitate to say
"brute force" - it's really just a question of where to spend your
research money, bang-for-buck).
	And, you know, most of the neat ideas in computer 
architecture really don't pan out? But faster circuits are always 
a win...


..> Allen(?) Baum (baum@apple.com) 
..> and Eugene Miya (eugene@aurora.arc.nasa.gov)
..> comment on the CISCiness of the TRON instruction set 
..> and operating system.

..> Someone else (I lost name) gives an example of a Hitachi 
..> instruction, with 3 levels of indirection and indexing in each
..> of two operands.

Indeed, the TRON instruction set is extremely CISCish, but it is 
also reasonably regular - each memory address might be considered
as an instruction stream in a simple, stripped down, instruction set
that consists only of ADD, SCALE, and INDIRECTION.  Sakamura
took Wulf's dictum "every address is a path" to the extreme.

There may be considerable parallelism within the addressing modes
of a TRON instruction - but does the encoding permit parallel decode
of addressing modes? (It doesn't seem to, to me. Please correct me 
if I am wrong).   It does seem to be possible to detect the end of
a variable length TRON instruction fairly easily, so parallel execution
of instructions (not just addressing modes) seems possible.

My basic problem with the TRON instruction set is that it emphasizes
addressing modes that access memory, while the trend has been to 
miminimize memory accesses by making them explicit, since computation 
is cheaper than memory.

Question: does adherence to TRON mandate use of the TRON instruction
set? Or is it possible to treat TRON like an ABI or ISA?

Question: what do the current TRON implementations look like? Are they
microcoded instruction dispatch, or what?  The timings I have seen have
been only for simple instructions. Do any TRON implementations use
tricks like a decoded instruction cache?

Musing: the emphasis on addressing modes raises the possibility of 
caches based on addressing mode rather than address - instead of
executing @(r3,@(r4,offset)) (or whatever) use the bytes of addressing
mode as cache tags.  There would be problems with consistency, but all
could be overcome. The question, of course, would be "is it worth 
overcoming them?".