BLARSON@ecld.#eclnet (08/09/84)
From: Bob Larson <BLARSON@ecld.#eclnet> When casting a pointer (48 bits) to an integer or long (32 bits) using Prime C, it is changed into a byte address (not useful to prime hardware/ microcode) and the extra information (fault and ring) is apparently dropped. When casting in the reverse direction, ring 3 is assumed. (Correct for all user programs.) The only section of K&R this violates is the sentence stating that "The mapping function is also machine dependent, but is intended to be unsurprising to those who know the address structure of the machine." (14.4) Bob Larson <Blarson@Usc-Ecl.Arpa> -------
jack@vu44.UUCP (Jack Jansen) (08/26/84)
> From: Bob Larson <BLARSON@ecld.#eclnet> > > When casting a pointer (48 bits) to an integer or long (32 bits) using > Prime C, it is changed into a byte address (not useful to prime hardware/ > microcode) and the extra information (fault and ring) is apparently > dropped. Pointers are 32 bits on the prime, not 48. The problem is that the ring information is stuffed in the upper 4 (or 5, I'm not sure) bits. I ran into this problem when I converted lots of unix programs that contained functions defined like func(args) and returned pointers. By the way, we have the C compiler sold by Prime, but it's *very* slow (spelled SSSSSSSSLLLLLLLLOOOOOOOsnore). Does anyone know of a better C implementation, running under PRIMOS rev 19? Jack Jansen, {philabs|decvax}!mcvax!vu44!jack
arnold@gatech.UUCP (Mister Snufilupagus) (09/02/84)
>>By the way, we have the C compiler sold by Prime, but it's *very* >>slow (spelled SSSSSSSSLLLLLLLLOOOOOOOsnore). Does anyone know of >>a better C implementation, running under PRIMOS rev 19? >> >> Jack Jansen, {philabs|decvax}!mcvax!vu44!jack >I did a C compiler for our Prime. The compiler itself it pretty fast. >However it generates PMA (Prime Macro Assembler) and *BOY* is that assembler >slow! > >west44!lee We here at Georgia Tech sell a C compiler for Prime 400 and 50 series computers. It runs under and requires our Software Tools Subsystem (which provides a *wonderful*, Unix-like programming environment). The compiler currently generates binary directly, and is *fast*! (Of course our machines are old, so they are *slow*). Anyway, pointers in GT C are always 32 bits. We don't use the byte pointer. Characters are actually 16 bits, right adjusted, and 0-filled words. The performance would be considerably *slower* if we used the field register operations to pack the characters, and the space cost isn't really that bad, considering the speed gain. The compiler used to generate assembler, and then call PMA to assemble it. PMA was 50% of compile time! This is still available as an option. To be truthful, the compiler does still have some bugs in it; unfortunately we don't have the expertise or manpower to fix them. It is usable, but not quite up to the "high quality" of the Unix compilers. We do have a very good run time library for it; almost all of Section 3 of the manual that can be implemented, has been, along with some of the i/o system calls. Furthermore, one can mix C routines with routines compiled by other Prime language compilers (Fortran, Pascal, Pl1, etc.). I apologize if this sounds like too much of an advertisement. I don't mean for it to; just publicizing the availability of other Prime C compilers.... -- Arnold Robbins CSNET: arnold@gatech ARPA: arnold%gatech.csnet@csnet-relay.arpa UUCP: { akgua, allegra, hplabs, ihnp4 }!gatech!arnold Can you tell me how to get, how to get to Sesame Street?
lee@west44.UUCP (Lee McLoughlin) (09/05/84)
>> From: Bob Larson <BLARSON@ecld.#eclnet> >> >> When casting a pointer (48 bits) to an integer or long (32 bits) using >> Prime C, it is changed into a byte address (not useful to prime hardware/ >> microcode) and the extra information (fault and ring) is apparently >> dropped. >Pointers are 32 bits on the prime, not 48. The problem is that the >ring information is stuffed in the upper 4 (or 5, I'm not sure) >bits. I ran into this problem when I converted lots of unix programs >that contained functions defined like >func(args) >and returned pointers. Commonly address on the Prime (in the 50 range) are held in 32 bits. This is because they are mainly word pointers. But you can have a character pointer which is 48 bits long. There is a bit in the word pointer which tells the hardware wether to bother with the extra 16 bits of the address or not. If you use this bit to represent hi/lo byte then you can use the 32 bit pointer to point at characters. This, of course, confuses everyone. > >By the way, we have the C compiler sold by Prime, but it's *very* >slow (spelled SSSSSSSSLLLLLLLLOOOOOOOsnore). Does anyone know of >a better C implementation, running under PRIMOS rev 19? > > Jack Jansen, {philabs|decvax}!mcvax!vu44!jack I did a C compiler for our Prime. The compiler itself it pretty fast. However it generates PMA (Prime Macro Assembler) and *BOY* is that assembler slow! Pointers on Primes are generally a real barrel of laughs. Good test of portability, miss out a cast and your proggy will dump on you. -- -------------- Lee McLoughlin <UK>!ukc!lmcl, west44!lee UKUUCP support.