Thread View: comp.sys.transputer
3 messages
3 total messages
Started by Andy Pfiffer
Thu, 19 Oct 1989 20:40
Re: GNU C for the transputer
Author: Andy Pfiffer
Date: Thu, 19 Oct 1989 20:40
Date: Thu, 19 Oct 1989 20:40
60 lines
2753 bytes
2753 bytes
+---- Erik Schoenfelder in "Subject: Re: GNU C for the transputer" - Tue Oct 17 @10:42pm | | An idea is to use the fast built-in memory of the transputer like | registers (with a accesstime between 1 cycle and 5 (?) cycles). | (Nice idea: It will be possible to get the address of a register variable :-) | But this results in a compiler for a (virtual) processor based on | the transputer-processor. +---- The problem with using the on-chip RAM as register variables is that if you want more than one GCC-produced binary running on the Transputer at a time, you have introduced a management problem; you must now context-switch on-chip RAM (or portions of it) between processes. It might be just the thing, however, for monolithic (as in one executable per node) environments. Perhaps you could limit each process to, say, 8 words of on-chip RAM and at process start-up, assign the "base" address of your pseudo-register set to an unused 8-word slot. That would limit you, however, to a few less than 128 processes (assuming a T800; you can't use all 4KB of on-chip RAM). Quite reasonable, actually. You don't get anything for free, however. You will still have to pay some cycles in referencing your on-chip pseudo-register set. Assuming we keep the base address of our pseudo-register set in a workspace-based variable, it might look something like this: ldl regbase ldnl 4 add . . in which case if your workspace is off-chip you've made matters much worse by *still* referencing your workspace. You can also play some games by using "mint" as a base address. A better solution might be to design a new Transputer that maintained a small, say 16-word, Transputer-maintained data-cache of the top 16-words of the workspace. The best solution might be to throw an R3000*, an R3010*, two 8-channel NCR-SCSI Sripts processors, a Virtual-Cut-Through router, and a few 100Mb/sec FDDI controllers into a centrifuge and pour the resulting goo into a 12x12 PGA. Andy *Acceptable substitutions may also include 88100 and 88200, or the daily special from Your Friendly Neighborhood RISC Store. -- Andy Pfiffer Topologix, Inc. (303) 421-7700 Trillium Diving Team 4860 Ward Road / Wheat Ridge, CO 80033 "...that's the way a Transputer works, right?"
Re: GNU C for the transputer
Author: Hubert Matthews
Date: Fri, 20 Oct 1989 10:35
Date: Fri, 20 Oct 1989 10:35
20 lines
1529 bytes
1529 bytes
One of the problems with porting a non-transputer C compiler to the transputer is the transputer's evaluation stack. One can simulate registers using on-chip RAM, in which case the evaluation stack is barely used and all of the loads and stores to and from RAM slow down expression evaluation a lot. If, on the other hand, one uses the stack for expression evaluation, then one has to be very careful about stack overflow (the stack is only three elements deep). A peephole optimiser would clean up a lot of the loads and stores associated with the first approach, but the second approach would need a quite different code generation algorithm. Would someone who has written for the transputer or ported any form of compiler to the transputer please comment on the feasability or difficulty of these two approaches, or tell us what transputer compilers really do. -- Hubert Matthews ...helping make the world a quote-free zone... hjm@cernvax.cern.ch hjm@vxomeg.decnet.cern.ch ...!mcvax!cernvax!hjm
Re: GNU C for the transputer
Author: Erik Schoenfelder
Date: Mon, 23 Oct 1989 15:24
Date: Mon, 23 Oct 1989 15:24
24 lines
1299 bytes
1299 bytes
In article <8910192040.AA20132@topologix.com> andy@topologix.UUCP (Andy Pfiffer) writes: Andy> The problem with using the on-chip RAM as register variables Andy> is that if you want more than one GCC-produced binary running Andy> on the Transputer at a time, you have introduced a management Andy> problem; you must now context-switch on-chip RAM (or portions Andy> of it) between processes. Yes, you are right. Andy> A better solution might be to design a new Transputer ... Andy> The best solution might be to throw an R3000*, an R3010*, two Andy> 8-channel NCR-SCSI Sripts processors, a Virtual-Cut-Through Andy> router, and a few 100Mb/sec FDDI controllers into a centrifuge Andy> and pour the resulting goo into a 12x12 PGA. And - don't forget to disconnect the transputer boards: We won't slow the system down. Erik -- Trillium ?
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads