Date: Tue, 06 May 1997 02:38:34 -0800 To: Multiple recipients of list CHIPDIR-L X-Comment: ChipDir Mailing List Sender: root@fatcity.com Reply-To: CHIPDIR-L@fatcity.com Errors-To: ML-ERRORS@fatcity.com From: Tim Forcer Subject: Re: SPARC (was orthogonality???) Organization: Fat City Network Services, San Diego, California X-ListServer: v0.9e, build 50; ListGuru (c) 1996-1997 Bruce A. Bergman OK. In reading this please remember I'm primarily a hardware guy who knows a bit about software, not the other way round. I've chopped big chunks of original post and some of the reply in an effort to aid legibility. >have always wondered >if SPARC register windows (besides looking very advantageous) had any >drawbacks... Sure. No such thing as a free lunch. >>.. The only time a stack is required is when the window >>shift would take you right the way round the circle and endanger values >>stored in the first active window. > >This sounds like a possible drawback... The object is to provide a "reasonable" level of stack/unstack-free operation without having to provide several Kbyte of on-chip registers. Even so, minimum 106 registers at 32 bits each is almost half a K. I'm told that most systems on startup rapidly burrow down to a point at which call/return activity will be within a given "band". That is, the code won't go up or down many nested levels of source from its mean. If the number of register windows is large enough, it will completely cover this band and register-to-RAM stacking/unstacking will only occur during startup, on (commanded) shut-down or during some exceptional event. If the band is too narrow, there will still be a significant amount of stacking/unstacking. >>It is up to the system designer to >>manage the process of detecting when stacking or unstacking is required. > >You mean the software designer? Isn't that dangerous? Q1 yes. Q2 no. Way it's done is: 'Mark' the last window in the circle as "invalid" (BEFORE it is used, so its local registers are usable). When a call/return or interrupt shifts the window to that point, SPARC initiates a "trap" (all SPARC out-of-sequence-operation triggers are "traps", including all interrupts and execution errors) which will be either "window overflow" or "window underflow". The overflow/underflow trap routines stack the contents of the appropriate window adjacent to the invalid window, mark that as the new invalid window, and return. Once these trap handlers have been fully debugged, the software designer can forget all about stacking, unless timing matters, in which case it will be necessary to devise a way of getting the system to operate in the middle of the band noted above. I don't know whether the assembler for underflow/overflow traps are public domain anywhere, this Department developed its own from first principles. It is possible to set up software development for the SPARC such that it doesn't shift windows at all, and simply stacks/unstacks like many other CPUs. Alternatively, one can implement a system which mixes the two, with two or more non-overlapping sets of windows to give true context-switching. >>.. difficulties may arise >>i) when you try to find cheap and effective development tools > >Is that a problem for the Sparc? Doesn't GNU support it? We use GNU C with a whole raft of associated in-house developed tools. In the early stages hand-assembly was common, and found errors in published information on SPARC behaviour. SPARC hand-assembly is not too bad, I produced 120 lines of it for a hardware confidence test EPROM. I can't comment on the qualities of commercially-available (or freeware) kernels for SPARC. >>ii) if you want to port existing applications or modules from another CPU > >Is that really a problem? Stack regimes are very locally solvable I would >think. (Are you talking embedding or Unix by the way?) The Department uses SPARCs in two very different ways. We have SPARC-based workstations both as development platforms for CAD of various types and for Computer Scientists to do their stuff. We also have a single-card computer used for both undergraduate experimentation and for a range of student projects. The latter is where I have my knowledge. The SCC is an embedded system, and the projects use it as such. Most of these applications simply re-use the standard kernel etc. For some applications things are not straightforward (eg, we have a project running to port Java to the SCC). The main development environment for the SCC is a networked PC host with full suite of GNU C and related tools. Surely one consideration in a port is how long it will take to get a result which is relatively well optimised to the new platform? If the underlying structure is very different, that process may be quite long. >>iii) when the customer later wants to do something totally different > >That's always a problem and he'll have to pay... But it's desirable to have some idea of what sort of future development is going to be easy and which very expensive. >>Perhaps this can be best illustrated by looking at the processors mentioned >>in comp.arch.embedded - x86 virtually absent, as is SPARC. I'd say there >>was a slight bias towards CISC in terms of number of posts. Perhaps that's >>because people have more problems with them! >> >>Oh dear - asbestos suit time. > >No, no, but explain more: Is Sparc as bad as x86? My experience of x86 is extremely limited (other than as a user of PC/DOS/Windows). What I do know is that I'm very glad that the SCC wasn't based on an x86 (I did the hardware design for it, and was involved in aspects of firmware). Part of the object of the SCC was that as much as possible should be "open" - signals, source code. The system is used by first year undergraduates as part of their introduction to microprocessors. >You're very cryptical here. X86 is quite expensive for embedding unless >you use 80186 or 386ex, but then you still don't really have a one-chip >solution, I think. When you need real power, embedding a Sparc may >not be the way to go, perhaps (strong)ARM, R1000, 486 or Hitachi's >RISC would be better? I have mainly embedded the Super8 and 6811 >(and a NEC 4-bitter). For more powerful chips we looked at the 68070, >29200 (already years ago), (hoped for the 2924x) and looked at the >Alpha and a ready to use 486 single board computer. "Our" specific SPARC CPU has been obsolete for some time. If we were starting again for the SCC and going for SPARC, we'd probably use SPARClite. We are currently looking at possible alternatives for embedded projects, and the StrongARM seems a strong contender. >A very important factor is if there are faster chips available, in case the >chip you've choosen turns out to be too slow... Our SCC runs at 20MHz max. (Given the size of the two-layer board that's probably just as well.) In a teaching environment, speed can be a problem rather than a virtue, although we have to be sort-of "state of the art". A difficult balancing act. Tim Tim Forcer Tel: (+44) (0)1703 593362 Fax: (+44) (0)1703 592053 Department of Electronics & Computer Science Room 3005, Building 35 The University, Southampton, SO17 1BJ UK