rdt201x@monu6.cc.monash.edu.au (mr c.m. greif) (08/05/90)
I have come across the problem of gcc (1.37.1) generating assembler
code that the pyramid as (5.0e) rejects.
The same assembler file does not upset the as (4.1) assembler
Can anyone give me some advice?
Thanks in advance
Simon Hill,
Robotics and Digital Technology,
Monash University, P.O Box 197, Caulfield East, VIC 3145 AUSTRALIA
Phone: 61-3-573-2092 Fax: 61-3-573-2745 INET: sdh@monu6.cc.monash.edu.au
Script started on Sun Aug 5 13:05:07 1990
$ name
name: Machine is Pyramid-MIS/2
OS is OSx200DNQ
node name is monu6
$ ln trial_gcc.c trial_cc.c
$ cat trial_gcc.c
#include <stdio.h>
#include <strings.h>
typedef struct item
{ float scl; /* signed scale factor for this element */
char* sym; /* comma-separated character string */
struct item* nxt; /* pointer to next item in list */
} item ;
/*
Returns the number of characters required to print the entry's
symbol and scalar.
*/
unsigned int
entry_width(it)
item* it;
{ unsigned int width;
width = (unsigned)strlen(it->sym);
if(width == 1) /* an empty symbol has one DELIM in it */
{ /* set the width for items with empty symbols */
switch ((int)it->scl)
{ case 0:
/* skip over intermediate zeros,
only set the width when 0 is the last item */
if(it->nxt == NULL) width = 1;
else width = 0;
break;
case 1:
case -1:
width = 2;
break;
default:
abandon("(%s): bad value of it->scl: %f, %d",
__FILE__, it->scl,(int)it->scl);
}
}
else
{ /* increment width for the sign */
width++;
/* subtract out the number of DELIMs */
width -= str_nu_tokens(it->sym);
}
if(it->nxt != NULL) /* not at end of entry list */
{ width += entry_width(it->nxt); /* add the width of the next item */
}
return(width);
} /* end of entry_width() */
$ gcc -v -c -S trial_gcc.c
gcc version 1.37.1
/rdt/rdt/rdt201x/lib/gcc-cpp -v -undef -D__GNUC__ -Dpyr -Dunix -D__pyr__ -D__unix__ trial_gcc.c /usr/tmp/cc001775.cpp
GNU CPP version 1.37.1
/rdt/rdt/rdt201x/lib/gcc-cc1 /usr/tmp/cc001775.cpp -quiet -dumpbase trial_gcc.c -version -o trial_gcc.s
GNU C version 1.37.1 (pyr) compiled by CC.
default target switches: -munix -mindex -mgnu-stdarg
$ strings /bin/as |fgrep AS_
@(#)AS_5.0e
$ as trial_gcc.s
as:
line 21: operands clobber for this op on isis
as:
line 50: operands clobber for this op on isis
as:
line 52: operands clobber for this op on isis
$ cat trial_gcc.s
gcc_compiled.:
.text
.align 2
LC0:
.ascii "(%s): bad value of it->scl: %f, %d\0"
.align 2
LC1:
.ascii "trial_gcc.c\0"
.align 2
.globl _entry_width
_entry_width:
adsf $8
movw pr0,-4(cfp)
movw -4(cfp),pr0
movw 4(pr0),tr0
call _strlen
movw tr0,-8(cfp)
cmpw $1,tr0
bne L1
movw -4(cfp),pr0
cvtfw (pr0),pr0
mtstw pr0,pr0
beq L3
mtstw pr0,pr0
bgt L10
cmpw $-1,pr0
beq L7
br L8
L10:
cmpw $1,pr0
beq L6
br L8
L3:
movw -4(cfp),pr0
movw 8(pr0),pr0
mtstw pr0,pr0
bne L4
movw $1,-8(cfp)
br L5
L4:
movw $0,-8(cfp)
L5:
br L2
L6:
L7:
movw $2,-8(cfp)
br L2
L8:
movw -4(cfp),pr0
cvtfd (pr0),pr0
movw -4(cfp),pr2
cvtfw (pr2),pr2
movw $LC0,tr0
movw $LC1,tr1
movl pr0,tr2
movw pr2,tr4
call _abandon
L2:
br L11
L1:
movw -8(cfp),pr0
movw -8(cfp),pr0
addw $1,pr0
movw pr0,-8(cfp)
movw -4(cfp),pr0
movw 4(pr0),tr0
call _str_nu_tokens
movw tr0,pr0
rsubw -8(cfp),pr0
movw pr0,-8(cfp)
L11:
movw -4(cfp),pr0
movw 8(pr0),pr0
mtstw pr0,pr0
beq L12
movw -4(cfp),pr0
movw 8(pr0),tr0
call _entry_width
movw tr0,pr0
movw -8(cfp),pr1
mova (pr0)[pr1*1],pr0
movw pr0,-8(cfp)
L12:
movw -8(cfp),pr0
retd $0
retd $0
$ cc -g -v -S trial_cc.c
$ as trial_cc.s
$ cat trial_cc.s
.stabs "trial_cc.c",0x64,0x0,0x0,L13
L13:
.data 0
.stabs "_cnt",0x60,0x0,0x4,0x0
.stabs "_cnt",0xfe,0x1,0x0,0x4
.stabs "_ptr",0x60,0x0,0x12,0x4
.stabs "_ptr",0xfe,0x1,0x0,0x4
.stabs "_base",0x60,0x0,0x12,0x8
.stabs "_base",0xfe,0x1,0x0,0x4
.stabs "_bufsiz",0x60,0x0,0x4,0xc
.stabs "_bufsiz",0xfe,0x1,0x0,0x4
.stabs "_flag",0x60,0x0,0x3,0x10
.stabs "_flag",0xfe,0x1,0x0,0x2
.stabs "_file",0x60,0x0,0x2,0x12
.stabs "_file",0xfe,0x1,0x0,0x1
.stabs "_iobuf",0x20,0x0,0x8,0x0
.stabs "_iobuf",0xfe,0x1,0x0,0x14
.stabs "_iob",0x20,0x0,0x38,0x0
.stabs "_iob",0xfe,0x1,0x0,0x14
.stabs "scl",0x60,0x0,0x6,0x0
.stabs "scl",0xfe,0x1,0x0,0x4
.stabs "sym",0x60,0x0,0x12,0x4
.stabs "sym",0xfe,0x1,0x0,0x4
.stabs "nxt",0x60,0x0,0x18,0x8
.stabs "nxt",0xfe,0x1,0x0,0x4
.stabs "item",0x20,0x0,0x8,0x0
.stabs "item",0xfe,0x1,0x0,0xc
.stabs "item",0x20,0x0,0x8,0x0
.stabs "item",0xfe,0x1,0x0,0xc
.data 1
.align 2
L23:
.string "(%s): bad value of it->scl: %f, %d"
.align 2
L24:
.string "trial_cc.c"
.text 0
.stabs "entry_width",0x24,0x0,0xf,L14
.globl _entry_width
_entry_width:
L14:
.stabs "it",0x40,0x0,0x18,0x10
.stabs "it",0xfe,0x1,0x0,0x4
.stabn 0x44,0x0,0xf,L14
.stabd 0x44,0x0,0x11
.stabs "width",0x40,0x0,0xe,0x20
.stabs "width",0xfe,0x1,0x0,0x4
.stabd 0xc0,0x0,0x2
.stabd 0x44,0x0,0x13
movw 0x4(pr0),tr0
call _strlen
movw tr0,lr0
.stabd 0x44,0x0,0x14
ucmpw $0x1,lr0
bne L15
.stabd 0x44,0x0,0x15
.stabd 0xc0,0x0,0x3
.stabd 0x44,0x0,0x16
cvtfw (pr0),tr0
cmpw $0xffffffff,tr0
blt L22
cmpw $0x1,tr0
bgt L22
movw L25+0x4[tr0*0x4],tr0
jump (tr0)
.data 0
.align 2
L25:
.word L21
.word L17
.word L20
.text 0
.stabd 0x44,0x0,0x17
.stabd 0xc0,0x0,0x4
L17:
.stabd 0x44,0x0,0x1a
mtstw 0x8(pr0),tr0
bne L18
movw $0x1,lr0
br L19
L18:
.stabd 0x44,0x0,0x1b
movw $0x0,lr0
L19:
.stabd 0x44,0x0,0x1c
br L16
.stabd 0x44,0x0,0x1d
L20:
.stabd 0x44,0x0,0x1e
L21:
.stabd 0x44,0x0,0x1f
movw $0x2,lr0
.stabd 0x44,0x0,0x20
br L16
.stabd 0x44,0x0,0x21
L22:
.stabd 0x44,0x0,0x23
cvtfd (pr0),tr2
cvtfw (pr0),tr4
movw $L23,tr0
movw $L24,tr1
call _abandon
.stabd 0x44,0x0,0x24
.stabd 0xe0,0x0,0x4
L16:
.stabd 0x44,0x0,0x25
.stabd 0xe0,0x0,0x3
br L26
L15:
.stabd 0x44,0x0,0x27
.stabd 0xc0,0x0,0x3
.stabd 0x44,0x0,0x28
addw $0x1,lr0
.stabd 0x44,0x0,0x2a
movw 0x4(pr0),tr0
call _str_nu_tokens
subw tr0,lr0
.stabd 0x44,0x0,0x2b
.stabd 0xe0,0x0,0x3
L26:
.stabd 0x44,0x0,0x2c
mtstw 0x8(pr0),tr0
beq L27
.stabd 0x44,0x0,0x2d
.stabd 0xc0,0x0,0x3
movw 0x8(pr0),tr0
call _entry_width
addw tr0,lr0
.stabd 0x44,0x0,0x2e
.stabd 0xe0,0x0,0x3
L27:
.stabd 0x44,0x0,0x2f
movw lr0,pr0
ret
.stabd 0x44,0x0,0x30
.stabd 0xe0,0x0,0x2
ret
$
script done on Sun Aug 5 13:06:53 1990
The assembler file trial_gcc.s is then ftp'd to a machine running
as (4.1) and assembles ok.
Script started on Sun Aug 5 13:16:21 1990
% name
name: Machine is Pyramid-9820
OS is OSx65MN
node name is bruce
% as trial_gcc.s
% strings /bin/as |fgrep AS_
@(#)AS_4.1
%
script done on Sun Aug 5 13:17:54 1990jonathan@comp.vuw.ac.nz (Jonathan) (08/06/90)
In article <1990Aug5.034045.2636@monu6.cc.monash.edu.au> rdt201x@monu6.cc.monash.edu.au (mr c.m. greif) writes: >I have come across the problem of gcc (1.37.1) generating assembler >code that the pyramid as (5.0e) rejects. >The same assembler file does not upset the as (4.1) assembler > The OSx 5.0 assembler seems to be saying that, on ISIS machines, the cvtfw and cvtfd instructions clobber their source operand, and that therefore the source operand of these instructions may not overlap the destination operand. I know how to fix GCC for these particular instructions. Follow-ups on the reported bug should be posted to gnu.gcc.bug. But I do not know if there are any other instructions that have similar restrictions on the ISIS architecture. Plausible candidates are cvtdw, cvtdf, and perhaps fixed-to-float conversions. The local Pyramid distributors do not understand this stuff, and did not respond to an enquiry about obtaining a Pyramid architecture manual. Can someone from Pyramid please answer this? -- ----------------------------------------------------------------------------- sane mailers: jonathan@comp.vuw.ac.nz | Proverbs for Paranoids, 3: UUCP: ...!uunet!comp.vuw.ac.nz!jonathan| {\em You} hide, {\em They} seek. | - Thomas Pynchon
admin@cs.exeter.ac.uk (Khalid Sattar) (08/06/90)
>>>>> In article <1990Aug5.034045.2636@monu6.cc.monash.edu.au> >>>>> rdt201x@monu6.cc.monash.edu.au (mr c.m. greif) writes: > I have come across the problem of gcc (1.37.1) generating assembler > code that the pyramid as (5.0e) rejects. > The same assembler file does not upset the as (4.1) assembler I didn't know that gcc ran on Pyramids, it this something recent? If I get gcc from a nearby archive will it compile or do I have to get someone's hack that made it work on Pyramid. We are running 4.4c on 98Xe -- Khalid Sattar JANET : K.Sattar@uk.ac.exeter.cs Computer Science Dept. UUCP : K.Sattar@expya.uucp University of Exeter INTERNET : K.Sattar@cs.exeter.ac.uk Exeter, UK. Tel : +44 392 264062
kenj@yarra.oz.au (Ken McDonell) (08/07/90)
jonathan@comp.vuw.ac.nz (Jonathan) writes: >In article <1990Aug5.034045.2636@monu6.cc.monash.edu.au> rdt201x@monu6.cc.monash.edu.au (mr c.m. greif) writes: [ stuff deleted ... see my earlier posting re. original problem ] >The OSx 5.0 assembler seems to be saying that, on ISIS machines, >the cvtfw and cvtfd instructions clobber their source operand, and >that therefore the source operand of these instructions may not >overlap the destination operand. I know how to fix GCC for >these particular instructions. Follow-ups on the reported bug should >be posted to gnu.gcc.bug. >But I do not know if there are any other instructions that have >similar restrictions on the ISIS architecture. Plausible candidates >are cvtdw, cvtdf, and perhaps fixed-to-float conversions. ... >... Can someone >from Pyramid please answer this? I'll try. The 6 instructions that are subject to source-destination conflict are as follows ... cvtwf cvtwd cvtfw cvtfd cvtdw cvtdf The conditions under which the conflict arises are a. S1 class, (r1 equal to r2) or (rx non-zero and rx equal to r2), or b. S2 class, (r1 non-zero or rx non zero) and ((r1 equals r2 and rx zero) or rx equals r2) Hope this helps. -- Ken McDonell E-mail: kenj@pyramid.com kenj@yarra.oz.au Performance Analysis Group Phone: +61 3 820 0711 Pyramid Technology Corporation Disclaimer: I speak for me alone, of course.
mccarrol@emerald.rutgers.edu (Mark C. Carroll <MC>) (08/07/90)
Gcc compiles fairly well on Pyramids in the ucb environment, but it requires an enourmous amount of disk space to properly bootstrap the compiler. The easiest way to get it is to just get the PUG Library Dist 3 tape. I've put gcc on it. (I've been working on g++, but no luck yet. If I get it done before I leave, it'll be on tape 4.) <MC> -- |Mark Craig Carroll: <MC> |"We the people want it straight for a change; |Student SysProg - LCSR | cos we the people are getting tired of your games; |Rutgers University | If you insult us with cheap propaganda; |mccarrol@topaz.rutgers.edu| We'll elect a precedent to a state of mind" -Fish
chris@utgard.uucp (Chris Anderson) (08/08/90)
In article <ADMIN.90Aug6114244@expya.cs.exeter.ac.uk> admin@cs.exeter.ac.uk (Khalid Sattar) writes: >I didn't know that gcc ran on Pyramids, it this something recent? If I >get gcc from a nearby archive will it compile or do I have to get >someone's hack that made it work on Pyramid. We are running 4.4c on >98Xe As of 1.37, that I'm aware of, gcc has included machine descriptions for the Pyramid. Pretty much it's compile and go to get it running. G++, on the other hand, is proving more difficult for me... I've had gcc running on OSx 4.4c and OSx 5.0d. Pyr 9825. So far we haven't had any problems with it at all. Chris -- | Chris Anderson | | QMA, Inc. email : {csusac,sactoh0}!utgard!chris | |----------------------------------------------------------------------| | My employer never listens to me, so why should he care what I say? |