dtynan@sultra.UUCP (Der Tynan) (10/18/88)
OK, I'm interested in the 32K series from National. So where do I turn for
more information? That's right. comp.sys.nsc.32k. And what do I find?
Nada! Zip! The occasional article that seems to slip by. Doesn't anyone
out there use this thing? Come on, some comments. How does it compare to
the Motorola lineup. What are people doing with it. How do they like it.
You know, USENET stuff!! For one thing, the GNU C compiler has machine
definitions for the 32K, but GAS doesn't. Is anyone working on this??
What about bugs in the ucode? I see that GCC refers to some bugs, in the
way that it generates code. Anyone got experience with this? What complete
systems are available out there? How much are they? Look, if this doesn't
start the ball rolling, I'll have to start misquoting people, and posting
incorrect data, just to get you 32k'ers to post something.
- Der
--
Reply: dtynan@sultra.UUCP (Der Tynan @ Tynan Computers)
{mips,pyramid}!sultra!dtynan
Cast a cold eye on life, on death. Horseman, pass by... [WBY]mlewis@unocss.UUCP (Marcus S. Lewis) (10/20/88)
In article <2582@sultra.UUCP>, dtynan@sultra.UUCP (Der Tynan) writes: > OK, I'm interested in the 32K series from National. So where do I turn for > more information? That's right. comp.sys.nsc.32k. And what do I find? > Nada! Zip! The occasional article that seems to slip by. Doesn't anyone > out there use this thing? Come on, some comments. .... There exists a group of individuals who are possibly somewhat less than overjoyed at the dominance of both the Intel and Motorola processors, and yearn for the return of the true hacker spirit. In keeping with this odd philosophy, we have decided to write an OS from scratch to facilitate the spread of the NSC32 family processors. We all (not sure how many there are) either have or or are trying to get "working" NSC processors. We could probably use some high-powered help. Our fearless leader will soon have a copy of GCC 1.28 (as soon as I mail it to him), and we have at least two other C compilers and at least two cross-assemblers. System #1 is "Bare Metal", sort of a CP/M clone, and does a few things. REAL (Real CPU, Real memory, Real program) is to be a multitasking system, hopefully suitable for embedded systems, as well as a usable, non-licensable FREE OS, available in source form for the asking, similar to the GNU project, though nowhere near so grand in scope. Interested parties should contact (via snail) Richard Rodman, at 8329 Ivy Glen Ct, Manassas VA 22110. Tell him I sent you, it could be worth some brownie points. He publishes a newsletter, roughly every other month, which is currently free. He also runs a BBS (or did before he moved), where all available sources are ready for download. I could use some encouragement fairly soon, as I intend to graduate in December and will probably lose my accounts on this system. Unless of course I decide to go for PhD. (shudder!) Marc Lewis: I don't even know if this will get where I send it, how can I tell you how to get back to me?
ewerlid@kuling.UUCP (Ove Ewerlid) (10/20/88)
In article <2582@sultra.UUCP> dtynan@sultra.UUCP (Der Tynan) writes: >You know, USENET stuff!! For one thing, the GNU C compiler has machine >definitions for the 32K, but GAS doesn't. Is anyone working on this?? If you read the article I submited some 5 (I guess) weeks ago you would have realised that someone is working on a ns32k-gas-port. This port is ready and running for my own ns32k system. The main problem is the linker. This problem is due to the huffman-size-tags used on displacements. If one uses positive styled offsets from segments those tags can be handled directly. One must ofcourse also make sure that only 4byte displacements are used (This is the normal case). With 'directly' I mean that one could adopt the linker to recognice tagged displacements from immediates. The linker must be explicitly told it is linking ns32k-code. Also note that the ns32k uses different endian styles in instruction operands (immediates and displacements) and in direct memory accesses. I guess the designer of the ns32k choosed the style in displacements due to the huffman tags (the immediates followed for generallity). The memory access style because it is most logical to have the lsb's at a lower address. (Yes I know, the endian concept is more religion than logic, but still ....) In the current gnu-linker negative offsets are used. One realizes that tagged displacements can't be used if 2's complement notation is utilized. Add 1 to 0xffffffff and you get 0, not 0xc0000000. Also subtract 1 from 0xc0000000 and you get 0xbfffffff not 0xffffffff. 2's complement must be used as segment A may be placed over or under segment B. If segment A has external references to B, 2's complement is a must if you want to target references from A to B in both cases. The problem can be solved in either case but one of the cases yields a better solution. If someone can prove that the above thesis is wrong, thats fine, as we don't have to bother about it than :-). More religion: The ns32k has the cleanest architecture of the common 32-bitters. Apart from the fact that assemblers and compiler specifications for the ns32k tends to get smaller it also has the right feel. For instance the m68k concept has mutaded beyond all grace as the instruction set and addressingmodes are a big specialcase. I guess the persons who uppgraded the 68000 to 68020 to 68030 were rather unhappy with the inhomogen architecure. A lot of ours wasted on specialcases or..... I don't want to talk about the i386. Guess the backward compatibillity of some CPU's are rather important!?!?!?! The ns32k has some missfeatures though. For instance, the offsets of the displacements are not from the displacement it self, it is taken from the begining of the instruction. Still this is nothing the programmer has to think about unless he/she attempts to write an assembler/dissassembler. Also the ns32k uses fields in the opcodes to encode operand argumnets that may be forward references. Still nothing the programmer has to think about. The instructions that uses this is a must since the ns32k doesn't have auto increment/decrement addressingmodes. The lack of those modes is in it self a bug. My experience with the hardware is similar the ns32k guys did a good job here to. There was some bugs in the first generation. What I mean hear is the overall feel of the chipsinterface to its suroundings. Conclusion: I don't think any one that has knowledge about the major 32-bitters will deny that the ns32k is the most well thought-out design. Ns32k is simply the cpu one chooses if there are no other constrains. Such as backward compatibillity of systems, second sources, what cpu is in the existing design, what cpu do I know best, price, real-time-constrains, speed, software, religion etc etc After all, it is the one that sells most that is winning or....
rfg@nsc.nsc.com (Ron Guilmette) (10/21/88)
In article <2582@sultra.UUCP> dtynan@sultra.UUCP (Der Tynan) writes: >How does it compare to the Motorola lineup. Can you say "F-15 vs. a hot air balloon"? Well, I guess I'm biased ;-) >For one thing, the GNU C compiler has machine >definitions for the 32K, but GAS doesn't. Is anyone working on this?? I have just got a new GAS from a fellow in Sweden that is supposed to be ready for the 32000's. Unfortunately, he has no 32000's to even test it on so I am doing the testing. I will be sending him changes when I can and he is working with FSF to get his (and my) changes into some future release of GAS. The first cut will only generate a.out format, and I will be working on COFF format output later. >What about bugs in the ucode? I see that GCC refers to some bugs, in the >way that it generates code. Anyone got experience with this? Every (non-RISC) microprocessor has microcode bugs. Ours are no different. I just got something in the mail from the people who publish "The Microprocessor Report" (an expensive trade magazine) where they were talking about how they were the first to reveal publicly the 20-item buglist for the '386. Fortunately, most of the bugs which reamin in production chips (both ours and those from other manufacturers) are benign and never even show up (except at the kernel level, and typically under very unusual timing situations) in most operating environments. Note also than most of the "bugs" refered to in the GNU stuff have never been independently verified. I believe that one GNU document even says that these are bugs which rms "thinks" are in the chips (i.e. maybe nobody ever really checked them all out). Also, many of the supposed bugs may only appear in chips which are now two generations old (i.e. 32032's or older 32016's). Further, note that some of the "bugs" which the GNU stuff talks about are really "assembler" bugs and not "chip" bugs, and they these bugs are in other (i.e. non-National) company's assemblers. >How much are they? How much do want to spend? You can get a kit for maybe a couple of hundred bucks complete. Or you can by an Encore-Multimax full-blown multiprocessor U*IX system for about a half a million bucks, give or take. Ron Guilmette National SemiConductor, 1135 Kern Ave. M/S 7C-266; Sunnyvale, CA 94086 Internet: rfg@nsc.nsc.com or amdahl!nsc!rfg@ames.arc.nasa.gov Uucp: ...{pyramid,sun,amdahl,apple}!nsc!rfg -- Ron Guilmette National SemiConductor, 1135 Kern Ave. M/S 7C-266; Sunnyvale, CA 94086 Internet: rfg@nsc.nsc.com or amdahl!nsc!rfg@ames.arc.nasa.gov Uucp: ...{pyramid,sun,amdahl,apple}!nsc!rfg
rfg@nsc.nsc.com (Ron Guilmette) (10/22/88)
In article <447@unocss.UUCP> mlewis@unocss.UUCP (Marcus S. Lewis) writes: > >There exists a group of individuals who are possibly somewhat less than >overjoyed at the dominance of both the Intel and Motorola processors... Yes. They are often called National Semiconductor employees. >... we have decided to write an OS from scratch ... I wonder if it has occured to you that you might be able to make some money doing that. >We all (not sure how many there are) >either have or or are trying to get "working" NSC processors. We could >probably use some high-powered help. I'm rather low-powered, but please describe your specific needs anyway. >Our fearless leader will soon have >a copy of GCC 1.28 (as soon as I mail it to him), and we have at least two >other C compilers and at least two cross-assemblers. Be advised that (a) GCC 1.29 & 1.30 have a rather insidious bug which affects the 32000 code generation which I am now tracking down, and (b) note that GCC will not work straight out of the box if you want to host and/or target it on/for a Genix system. I will gladly send you patches to 1.30 if you just E-mail me and ask for them. I am also working on alpha testing of an unreleased version of GAS for the 32000. It generates A.OUT format binaries (not COFF). It doesn't quite work on the Sequent-Balance yet, but I think that it is pretty close. >REAL (Real CPU, Real memory, Real program) is to be a >multitasking system, hopefully suitable for embedded systems... I like it already. > I could use some encouragement fairly soon, as I intend to graduate >in December and will probably lose my accounts on this system. Unless of >course I decide to go for PhD. (shudder!) Why shudder? If it feels good, do it. Ron Guilmette National SemiConductor, 1135 Kern Ave. M/S 7C-266; Sunnyvale, CA 94086 Internet: rfg@nsc.nsc.com or amdahl!nsc!rfg@ames.arc.nasa.gov Uucp: ...{pyramid,sun,amdahl,apple}!nsc!rfg -- Ron Guilmette National SemiConductor, 1135 Kern Ave. M/S 7C-266; Sunnyvale, CA 94086 Internet: rfg@nsc.nsc.com or amdahl!nsc!rfg@ames.arc.nasa.gov Uucp: ...{pyramid,sun,amdahl,apple}!nsc!rfg
grenley@nsc.nsc.com (George Grenley) (10/22/88)
In article <447@unocss.UUCP> mlewis@unocss.UUCP (Marcus S. Lewis) writes: >There exists a group of individuals who are possibly somewhat less than >overjoyed at the dominance of both the Intel and Motorola processors, and >yearn for the return of the true hacker spirit. In keeping with this odd >philosophy, we have decided to write an OS from scratch to facilitate the >spread of the NSC32 family processors. We all (not sure how many there are) >either have or or are trying to get "working" NSC processors. We could >probably use some high-powered help. Our fearless leader will soon have >a copy of GCC 1.28 (as soon as I mail it to him), and we have at least two >other C compilers and at least two cross-assemblers. > System #1 is "Bare Metal", sort of a CP/M clone, and does >a few things. REAL (Real CPU, Real memory, Real program) is to be a >multitasking system, hopefully suitable for embedded systems, as well as >a usable, non-licensable FREE OS, available in source form for the asking, >similar to the GNU project, though nowhere near so grand in scope. This is good news. For those of you who are associated with Universities, we have, among other things 532 designer kits (a good way to get a 532 chip), and also VME332 boards - 15 mhz 332 cluster, good for realtime or unix. These items can be bought very inexpensively (but not free). Unfortunately, 332 chipsets and 532 chips at "student" prices are pretty hard to come by. If I can find one I'll let you know. George Grenley
ca063@unocss.UUCP (Thomas Davis) (10/22/88)
From article <7208@nsc.nsc.com>, by rfg@nsc.nsc.com (Ron Guilmette): > In article <447@unocss.UUCP> mlewis@unocss.UUCP (Marcus S. Lewis) writes: >>Our fearless leader will soon have >>a copy of GCC 1.28 (as soon as I mail it to him), and we have at least two >>other C compilers and at least two cross-assemblers. > > Be advised that (a) GCC 1.29 & 1.30 have a rather insidious bug which affects > the 32000 code generation which I am now tracking down, and (b) note that GCC > will not work straight out of the box if you want to host and/or target it > on/for a Genix system. I will gladly send you patches to 1.30 if you just > E-mail me and ask for them. > > I am also working on alpha testing of an unreleased version of GAS for the > 32000. It generates A.OUT format binaries (not COFF). It doesn't quite > work on the Sequent-Balance yet, but I think that it is pretty close. > I'm working on a 32016 system here at UNO (Mark Lewis pointed me at it..) I was thinking of using GCC to do my system code (hey, I've got some ideas on how to do it..). There is also another bug in GCC, that has been in it from 1.22 to 1.30 (Try the MAZE.C program posted to comp.sources.misc(?) GCC's a.out bombs it. It trys to write to the text segment (no no..)). Anyway, I convinced National to send me 2 32016 developers kit, under the university program (I need to get hold of them.. They arrived, but they need my university address, but I haven't had the time to send it to them..) REAL SOON NOW, I hope to get the hardware up and running.. It's going to be fun, having a board with about the same power as a VAX. In fact the instructor of the class that I'm doing the system for cann't wait for it be working (he's Intel. I laugh in his face every time he mentions 'segments'.) -- Internet : ca063%unocss.unl.edu@RELAY.CS.NET | Thomas Davis BitNet : conslt16@unoma1 | Consultant, Campus Computing UUCP : uunet!btni!unocss!ca063 | U. of Neb. @ Omaha, NE
night@pawl13.pawl.rpi.edu (Trip Martin) (10/24/88)
In article <7219@nsc.nsc.com> grenley@nsc.nsc.com.UUCP (George Grenley) writes: >This is good news. For those of you who are associated with Universities, >we have, among other things 532 designer kits (a good way to get a 532 chip), >and also VME332 boards - 15 mhz 332 cluster, good for realtime or unix. >These items can be bought very inexpensively (but not free). How much do the 532 designer kits and the VME332 boards cost? Trip Martin night@pawl.rpi.edu userffs7@rpitsmts.bitnet
terryk@pinocchio.Encore.COM (Terence Kelleher) (10/24/88)
In article <7189@nsc.nsc.com> rfg@nsc.nsc.com.UUCP (Ron Guilmette) writes: >In article <2582@sultra.UUCP> dtynan@sultra.UUCP (Der Tynan) writes: > >>How much are they? > >How much do want to spend? You can get a kit for maybe a couple of hundred >bucks complete. Or you can by an Encore-Multimax full-blown multiprocessor >U*IX system for about a half a million bucks, give or take. > The Multimax starts out at $89,000. At this price, you get 2 32332 processors, 16 Mbytes of memory and 300 Mbytes of disk. It comes with either SysV or 4.2 unix. Terry Kelleher, Encore Computer UUCP: {bu-cs,decvax,necntc,talcott}!encore!terryk Internet: terryk%pinocchio@multimax.ARPA
ewerlid@kuling.UUCP (Ove Ewerlid) (10/25/88)
In article <7189@nsc.nsc.com> rfg@nsc.nsc.com.UUCP (Ron Guilmette) writes: >I have just got a new GAS from a fellow in Sweden that is supposed to be >ready for the 32000's. Unfortunately, he has no 32000's to even test it ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >on so I am doing the testing. I will be sending him changes when I can and >he is working with FSF to get his (and my) changes into some future release >of GAS. The first cut will only generate a.out format, and I will be working >on COFF format output later. True and not true. I don't program to bare metall...... I do have a ns32k system alas not Unix based. This makes it rather hard to test linker related hacks. Ron Guilmette has assisted me in the Unix related issues with advice and information. As of today we both work on the source of the port. The code generating part of the port is quite complete and we get intact text+data+bss segments. (I use it) This is however to no use for an Unix user if he/she don't have a linker that can handle the rather special ns32k displacements. The GNU-linker must be hacked to cope with the ns32k. (Sigh! took some thinking to realize) As I now have info on how the sequent-linker wants its relocation info setup, a version of the port with those changes have been submitted to RG. I think that a sequent-version of the port can be realized in a near future. (If there are anyone that have a *bsd-unix* based ns32k system near Uppsala, Sweden. Let me know and I'll pop by some night for some serious gnu-link porting :-) The system I have is a complete homebrew ditto. Built some 4 years ago arund a 32016+mmu+icu. All the software is of rather primitive homedesign and is rather out of date. Who want's to use a primitive and buggy editor when the GNU-emacs is available. (Not on my system though). The point is that one gets to use the machine under the above circumstances. And this is a very important point as the ns32k architecture represent the only 32bit CISC cpu one wants to use. The ns32k is the only CISC design where one can see that there has been serious thinking before the final design was cast. If you want to hack, do it on a ns32k! However, even the stars have dark spots, and the ns32k is no exception. As far as assemblers are concerned, it is important that the instructionset is uniform. The ns32k is unsurpassed at this point. However, when there are instructions that don't fit in the existing uniformity, one see it. In an earlier article I presented the, as I see it, odd syntax of the CINV instruction as presented in the 32532 datasheet. The syntax introduces a variable number of operands and leaves the older optionlist syntax. This can ofcourse be handled by the assembler at the cost of generality. The assembler programer however must use two syntaxes for essentially the same thing. Quite unnecessary. I hope that any new instructions in the 32732 design uses the same syntaxprinciples as used before. The pressent syntax is perfectly satisfactory. I don't think that the inventor of the CINV syntax is the same as the one who designed the original instruction ditto. Or is this another bold missunderstanding........... /Ove Ewerlid
donm@bucket.UUCP (Don McGlauflin) (10/26/88)
In article <7208@nsc.nsc.com> rfg@nsc.nsc.com.UUCP (Ron Guilmette) writes: >In article <447@unocss.UUCP> mlewis@unocss.UUCP (Marcus S. Lewis) writes: >> >>There exists a group of individuals who are possibly somewhat less than >>overjoyed at the dominance of both the Intel and Motorola processors... > >Yes. They are often called National Semiconductor employees. One of the major reasons for dominance of certain processors is that engineers LIKE them, and design them into systems. Did you know that a certain group of (ex) National employees FOUGHT to keep from having to use National processors in their board products? Don McGlauflin
rfg@nsc.nsc.com (Ron Guilmette) (10/28/88)
In article <879@kuling.UUCP> ewerlid@kuling.UUCP (Ove Ewerlid) writes: >I do have a ns32k system alas not Unix based. >This makes it rather hard to test linker related hacks. Sorry for the misunderstanding Ove. I stand corrected. I guess I should have said that you have no U*IX-based 32000 system to work on. -- Ron Guilmette National SemiConductor, 1135 Kern Ave. M/S 7C-266; Sunnyvale, CA 94086 Internet: rfg@nsc.nsc.com or amdahl!nsc!rfg@ames.arc.nasa.gov Uucp: ...{pyramid,sun,amdahl,apple}!nsc!rfg