Path: utzoo!yunexus!geac!syntron!jtsv16!uunet!mcvax!enea!kth!draken!bmc1!kuling!ewerlid From: ewerlid@kuling.UUCP (Ove Ewerlid) Newsgroups: comp.sys.nsc.32k Subject: Re: Where is everyone??? Keywords: GAS GNU NSC Message-ID: <879@kuling.UUCP> Date: 25 Oct 88 11:28:51 GMT Article-I.D.: kuling.879 References: <2582@sultra.UUCP> <7189@nsc.nsc.com> Reply-To: ewerlid@kuling.UUCP (Ove Ewerlid) Organization: Dept. of Computer Systems, Uppsala University, Sweden Lines: 58 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