koreth@ssyx.ucsc.edu (Steven Grimm) (03/08/88)
OK, I've received a few requests for this information, so here's the Abaq preview from comp.sys.atari.st a while back. Enjoy... +New! Improved! Now 200% Artificial-+-+-----------Steven Grimm------------+ |# # @@@ **** &&&&& $$$$$ % %| | ARPA: koreth@ssyx.ucsc.edu | |# # @ @ * * & $ % %+-+ UUCP: ...!ucbvax!ucscc!ssyx!koreth| |### @ @ **** &&&& $ %%%%%| |___________________________________| |# # @ @ * * & $ % %+-+"Things are only impossible until | |# # @@@ * ** &&&&& $ % %| | they're not." - Jean-Luc Picard | +-----with NutraSour(TM)! No natural colors or preservatives!------------+ ------------ Article 4404 of comp.sys.atari.st: Path: saturn!jade!ucbvax!sdcsvax!ucsdhub!esosun!seismo!uunet!portal!atari!neil >From: neil@atari.UUCP (Neil Harris) Newsgroups: comp.sys.atari.st Subject: Abaq Keywords: transputer,abaq Message-ID: <912@atari.UUCP> Date: 21 Dec 87 20:43:06 GMT Organization: Atari Corp/Mktg Lines: 205 Here is some information on the forthcoming Abaq system, straight from its developers at Perihelion: THE ABAQ written by Perihelion, Ltd. Hardware Specification The base machine outline specification is as follows: T800-20 Transputer 10MIPS, 1.5 Mflop Three 20Mhz links, buffered 4Mbyte DRAM 1 Mbyte dual-port video RAM Colour blitter True DMA SCSI port for 40M (minimum) hard disc Three internal expansion slots 68000 Mega ST as I/O processor (plug in card connects fourth 20Mhz link) Screen Resolution and Use The table below lists the screen resolutions and their probable typical use. All the following are at 60Hz with portrait orientation. Mode Resolution Width Description 0 1280 x 960 4 bits/pixel 4 bits/colour or monochrome (Desk Top Publishing, engineering drawings) 1 1024 x 768 8 bits/pixel 8 bits/colour (CAD, colour pictures, graphs) 2 640 x 480 8 bits/pixel 8 bits/colour 2 screens (Animation) 3 512 x 480 32 bits/pixel 24 bits colour, 1 overlay bit, 7 tag bits (True colour, smooth shading, 3D modelling) The Blitter The Perihelion blitter is based on work done by Dr Phil Willis of the University of Bath. It provides meaningful operations with colour and colour look-up tables (CLUTs) and implements very fast 2-D raster graphics operations, such as fast font drawing. It also provides a 32-bit wide pipeline (with four tests on each of eight pixels concurrently), and is synchronised with blanking. Using the blitter, square area fill takes 128 megapixels per second, arbitrary two colour character drawing takes up to 64 megapixels per second, and full 2-D block copy takes 16 megapixels per second. Expansion Capability The Perihelion design provides for three expansion cards within the box. These can be memory cards, providing a maximum of 64Mbytes using 4M parts, or various versions of alternative graphics cards. The full transputer bus is brought out so any type of peripheral may be connected. The expansion sockets also bring out the transputer links and control signals. This means that cards containing extra transputers can be added, and the size of the cards allows for four transputers with up to 1Mbyte of RAM each on a single card. One workstation can therefore contain 13 processors. Other link connections can be made outside the box to parallel processor farms of multiple processors. The link connections can also be made to fast peripherals such as a laser printer or disc server. The Transputer The T414 is a 32-bit processor that consists of a RISC style CPU, 2K of fast on-chip RAM, an external memory interface and four serial links which may run at 5, 10 or 20 Mbits/second. The T800 is similar except that it also contains a floating point processor and 4K of RAM. The programmer's model consists of a three register evaluation stack, a workspace pointer and an instruction pointer. A small number of instructions exist for loading and storing values on the stack and for altering the flow of control, the remainder operate on operands on the stack. The processor has microcoded support for processes at two priority levels. High priority processes may preempt low priority processes after any instruction and run until they give up the processor. High priority processes are essentially equivalent to interrupt routines on conventional processors. Low priority processes are round-robin scheduled on a timesliced basis. Timeslicing only occurs on particular instructions which are defined so that the minimum of state need be saved; process switching is therefore very fast. The transputer achieves inter-process communication through channels, which are single words of memory. Two processes that wish to communicate rendezvous at a channel and exchange data by copying from one buffer to another. As this is implemented by the microcode, the cost of copying lies only in the memory accesses for the data and not in instruction fetches. Communication is strictly one-to-one and channels may not be shared by more than one sender or receiver. The inter-processor links are designed to behave exactly like channels, and are used with the same instructions. -------------------------------------------------- Parallel Programming The unique aspect of the Atari/Perihelion design is that is provides multiple processors within a single workstation. The use of multiple processors means that is is possible to write application programs which make use of the possible parallelism inherent in such systems. Application programs can run under Helios using three programming philosophies. The first of these is the traditional programming model. A program can be taken from another environment, such as Unix or a PC, and with little or no change converted to run under Helios. C and the Unix C library is provided, and such programs will run as a single process in the machine. Other programs, again probably from Unix, will run in several sections all of which may be run in different processes and connected by pipes. Helios encourages the use of many small programs which work together to create a final product. A common example is a pre-processor, a compiler front end, a compiler back end, an assembler and a linker. These can all be run together with intermediate connections made by pipes. Under other operating systems the different processes are timesliced on the one single processor. Under Helios these different processes can be allocated to different processors, so that the individual parts actually run at the same time. This type of "per-process" parallelism is easily understood, and many applications are already in this form. Examples include a word processor with background spooling and spelling checking or background jobs such as message systems or archiving. If an application is being altered then the use of extra processes should be kept in mind. The final way in which parallelism may be exploited is by the use of parallel algorithms. These tend to be hard to find for programmers used to the sequential nature of normal computers, but a look at the real world shows, of course, everything running in parallel. Applications using parallel algorithms will normally be written from scratch with such ideas in mind. The benefit is that such programs will run much faster when the user provides more power in the form of more processors. Many examples of parallel algorithms exist, such as ray tracing, spreadsheet calculations, even compilers. ---------------- Implementation Helios presents a low level interface that should be familiar to programmers who have worked on Unix. Each user runs a number of tasks which can communicate between themselves using a simple message passing protocol. A message may be transferred between two tasks in the same machine or between tasks in different processors; in each case the call is identical and the message is copied rather than passed by reference. Each task is constructed from a number of interconnected transputer processes which can communicate either by message passing or by sharing data. Different tasks may be written in different languages as all communication at this level is by message passing. The design of Helios is based on the client-server model, where application tasks request services from system provided server tasks. These server tasks may be present in any or all of the processors available, although each processor must run the bare minimum of the name server which identifies the location of other services. Other servers include file handlers, window managers, date servers, spoolers and so on. All servers respond to a general server protocol which is designed so that servers may be stateless and hence unaffected by crashes and communication losses. This mechanism allows a wide choice in the way in which servers are implemented; for example, floppy discs will be written using the MS-DOS format while winchester discs will use a format similar to Unix. As noted above, the transputer does not contain any memory management unit and none may be added externally. Helios assumes that each processor is allocated to a single user, and protects processors by a capability mechanism. An access matrix is used to implement a filing system control scheme. ---------- System Tools Helios is written in a mixture of transputer assembler and C. System tools include a macro preprocessor, a C compiler, an assembler and a linker. In fact these last two items are the same program as the transputer has a variable length instruction set that requires a 'code growing' algorithm to ensure optimal code lengths sequences. This must be performed in the linker once all external references have been satisfied. A debugger that allows one transputer to investigate another will also be included in the package (although not in Version 1.0). Third party software developers are providing Pascal, Fortran, Lisp and BCPL as well as the traditional transputer language occam. ---------- User Interface The user interface consists of two parts: a command line interface similar to the Unix C-shell which provides the usual commands such as grep, ls, more, and so on; this will be coupled to an implementation of Xwindows V11 to provide the now familiar windowing mechanism. The system will appear similar to a more conventional machine, except that when the commands are piped together the operating system may make use of more than one processor to run the commands concurrently rather than timesliced as in a single processor environment. The programmer's interface will be complemented by a 'point and push'graphical interface for the less experienced user. This will use a mouse and pull-down menus and will be implemented on top of Xwindows. -- --->Neil Harris, Director of Marketing Communications, Atari Corporation UUCP: ...{hoptoad, lll-lcc, pyramid, imagen, sun}!atari!neil GEnie: NHARRIS/ WELL: neil / BIX: neilharris / Delphi: NEILHARRIS CIS: 70007,1135 / Atari BBS 408-745-5308 / Usually the OFFICIAL Atari opinion