jeff@polyof.UUCP (A1 jeff giordano ) (11/30/88)
I just ftped the Gcc stuff for ST-MINIX and found out that I need some things from the standard Gcc distribution. Could someone please tell me where to get it? Please respond by Email, if lots of other people want this info I will post it. Than You- Geoffrey Giordano INET: jeff@polyof.poly.edu (128.238.10.100) UUCP: ...!trixie!polyof!jeff
jk0@clutx.clarkson.edu (Jason Coughlin,221 Rey,,) (12/08/88)
How does one go about getting any Gnu "product"? Either by ftp or by sending mail. Thanks in advance. ------------------------------------------------------------------------------- Jason Coughlin ARPA : jk0@clutx.clarkson.edu BITNET: jk0@clutx
HBO043@DJUKFA11.BITNET (Christoph van Wuellen) (02/20/90)
After tracking down some difficulties with my MINIX-Port to the mc68000
(message follows), I noticed a bug in GCC compiler (version 1.35) when
doing a zero-extend on a quarterword (to a 16-bit-word) while pushing
the resulting value on the stack:
char c; .... test3(c & 0377) produced the following code:
clr.w -(a7)
move.b -1(a6),-(a7)
which is VERY wrong (4 bytes pushed instead of 2, the byte is at the wrong
place. This is, in fact, the strategy to to the extend when loading it into
a data register.
The error is in file m68k.md at line 1167. It is very obvious. Copy the
material for zero-extending a byte to a long from few lines below to this
place, change clr.l to clr.w and the offset 3 to offset 1, and GCC produces
the correct code
clr.w -(a7)
move.b -1(a6),1(a7)
I would like to hear if this error is present in the actual version of GCC
(1.36, I think) so, would everyone try this five-liner:
test()
{
char c;
test1 ( &c); /* this prevents the optimizer from being too skillfull */
test2 (c & 0377);
}
Translate it with -S and -O switches and look at the assembly code.
Please, tell me or post your findings.
If it should be an so-far-unknown bug, we should tell it to the FSF guys.
It seems we are the only group using 16-bit ints, thus the only group where
the error can occur.
Christoph van WuellenHBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) (01/30/91)
Since it was requested, my GCC patches:
m68k.md.cdif: fixes an error in the code gen for doing
8-->16 bit unsigned extension while pushing something on the stack
c-typeck.cdif, fold-const.cdif:
if you compile the new c-typeck.c, fold-const.c with -DCVW_SIZEOF_HACK,
gcc will generate 16-bit 'sizeof' for sizes less than 32767 when in 16-bit
mode.
Thus,
put(sizeof(long)) will be equivalent to put(4), while the original
gcc passes a long (32-bit) argument here.
long l[20000];
put(sizeof(l)) will be equivalent to put(80000l). This is the same
behaviour as c68, which treats sizeof() as a int constant when <32767,
as a long constant when >32767.
All this is not very elegant, but gcc can keep the MINIX sources now.
A statement from fdopen.c which cannot be compiled in 16-bit mode using
the original gcc:
.... malloc(sizeof(FILE)) .....
My personal opinion is that a 32-bit sizeof value is very natural on an
68000 and that the code is broken, but nevertheless....
for historic reasons, malloc expects an int argument, not a long.
You could argue that 16-bit ints are garbage on an 68000 anyhow.
C.v.W.
Here is the patch:
begin 644 gccdiff.shar.Z
M'YV-(Q)009-F#HB"(,* F(.F#!LV">6,(6BGC L% :64:?.F(H@R%>7DH4/0z
MS9F$8CJ62>B&S$$W8]C4(9/&) B2*\?4H0."34V+& 4V= -"3AVB.(N6F</Sy
MC9F;#4&82<-F)4DY;^J<0;,0S<41+<*VT,FSH9PR8L.2!6$6;=JU;=..W<FVx
MS-FT(S"&>"&FY@N&&+N&D:,#A.$I#1^"""*1HMV@4HY"76GFS<,W=VJ>I%,&w
M#\_,)$'P]<OPYAL08\Z&X:PCZ)@W;J:>>='&!HXU+MJ0<3&&IAG7+>CD@5-Fv
M#.[>:7X'K,R&S%C83'G[#CP0X>"):3RF+K.Z#)G"5.JL5!*&J(P<(&3$T %Cu
M?0P8(&+DR!%#P9C5('CP ,%E"I(@4GQ1Q!-&@. #:K#)1IMMN.DF77(*J" At
M"+7=EMMN;\B1QADUA<&&4'6 \,08/,40 P@PX*####7H(%]\\\&@@%@4,G@As
MB"*2&-^)*:YH@PXRT !C#C)*:.212*H0X80QR ###"PT"0-Z1RI@V)4@[&$Er
MEE<F!P(*4A1QA!-/?(E%$5A 82:::J+P!G%RE$?&'%O T 4+**: )PPII+!Eq
M H;UT ,(4U 1Q!!+? '%$TDX0441 88Y9A5-^!D"" F<14<=<A#%A0@QR5&"p
M"W> 4$(+7.S 446CBF%J#"R4 ,.G.VS)Y4=LS%'&GYIRZJD(JY;1ZJNQSKI#o
MJ,/*2JNM5_8Q8UCQ.0EEDTZ"D!:SAFEYJV%>@BDFF6NF&6Z;;]HE)YUV[JEGn
MGGX:!B@(@A)J****,NHHI%](Z@2EEG*IY:6WEAMG2^AV 2\(9XJ+0L+DPGENm
MG7?FJ6ZMEXZ0'!EE/-7$$U0\(<433 2A0,479TSH$5.,O&VOG?('*AMRD&HMl
M"K*FD&JPR<(: \U\+ENQ0[JJ?"O+OX8J<PL\VZRJ2CFS@ *L-?L,P@AEM 3Ak
MS[GN"C"71+L<:JFR H'JTA6Y6@+4, #QM,TB4#QUU=-M;9BSV^(:M+M=?XJSj
M"V:CG2JR?)LZ:]O8@N"L?P *2*!]^.G''^(!#EC@@6,$-UQQQTUG)&J6$V<<i
M;RYDN"&.Y!$5 PXHTL >#$#:,*2,-%8NG.?')= $;""4GA[J[^E @XKJ#5E?h
MDL1+N*0*(-1P0PTLU("#D%72J#SS-L1P@[5B;:GME577T<9-9Y7QQ6L8(UC^g
MH%2$6<070SQ!1!%?SEY&"K4:IL *4Y?\U!!67/'%%$G0@N2^\!]$W8][GK$+f
M4L*'FC PY0MT>,,7YI &/93!*1"\' KH=T##T(&!=*@5_CKX$3=X#WQE$!_Ye
M<O*&\X$@?4587_O>%[_+<7"$6.K6"N$U*"-4P0E#H$(2GN"$+U A"U H0KO\d
M53AN/04%Q"%#>>B0AC& @ ]\ ,$=!N.&+\#A#37AC!R^,)@TD&2)"=ABIS3Sc
M)1%0T().20@<X. 3[Y@F(5(Y"HG2@#OYB>"&V^+)H,10!ZJ0X0MA_%(, (DEb
M9^'/,$!;B0Y;N))X68%11# B$I5(PFQULDM/C.(4JWC%+*JQBU\,HUW(J*$Sa
M'C"-7&0C"MQ8P0L^)0QSK*-+(HA'.X!QEY?[HP@#>3!"&A*1;N#)VH;92!)&z
M\I,>[,$;Q5>3+XAA)$M!@?P ^0(E/1)Y58##'=N")R_E(2M*V53+Z( G-[R!y
M)&Q$R$3*<P;O7.2;+XP*<]B &3;N<"*8,XB7DC+-@QBD*G,P"$G* X(9R. &x
M-KC!/0V#O"0@A2 &N8^N\,03>3J0)[P\01A/ ()K-O"!$9Q@+3$HOPXB[PHYw
M*8\[>=(9.,CII'2 H 2GR=++O<0G;EA)6TI:G##4(6CX-",(CKH4J61H#!DSv
M8P:)@Z<[$&0B!NW)&^X#$5XRQSFO<4-TQN#2%Y"P6S!<7Z.HP+Y"$3 )1T""u
M-E,@*/B8P 0O5-\7UMI6MC+A"5>8:WX&Y5"(WL!/C^22('&J4Y7"T0Q3+<-<t
MATG"KH4U)#D]BAD-HDT\"2$)5)B"HO#U0]"R )IU2RV7CIA$185I"$D (!%1s
M,,\QRN\+[L18GX9)M:R)!GE6Q<\^,2-0A49%=!QR@X?,MQ(5F#6QDSQ?#W\8r
MQ"$6D;6<3*PGM0O*+XDRF:3$HA:YZ$4P)G.5970E_F"Y1IO,DJ>WS&4:[,A+q
MA9A!CU3L8S Y6+>N&;,YR%3F(NO');IUE[:4Y"$(+IF$3&+73\4CWO&21Y_Fp
MY<!UT8.6#8+$ AO, #[7PE(W03 $V&#V)2==B4)JFU6.G 4J#(7-2C1+!Q=0o
MU*Q8LJR)[9)9-VSV2]-$IC6QR=EM>A:THDUB@$I+A=.Z*P$"V:1KBP!;V3KAn
M2[6-+&XIN=L#4LUJ3QDQ__P'0 $2B("'6@((G+LE V_I@RE4 .049P3&\<1Qm
M_?E/Y AD(*<VYSEBK3%R?K.YKP)ZK*'3T!D$(I[<,30&KCN=BU@'Z=<]JP5^l
M!BMT!&T[W.E.!KQC'0U:]![A'2_"1IIP#&: @RC18 9K3C6-5MWJ&-3 =2'&k
ME(&;.3<OZX_$_?M? =8P"4<$,Z[PI]&<YI2^$9VKL<&X3"UI-W.B)$HB30#j
M&\)P!@C&B2;Y52X;**O=Q;X&#GG8,L8FV\FT:C*)@AV4MKGM[3" FX_B!L$/i
M7L*9>MKV<NI>26&.0L$S!/60M\UM&9AIF,I(1'Q38;8&Z<!(PW0MA =TY-O h
M_%M@DWG89R[VFG$, @9L:<1!(,,N[W :&]"@!7WIZ'G];1#0<,7E,%?J6>90g
M!S;4&%M%" -6!W,&[U6MHP;A4$6(XL";L!P$8!@I". P7ZC.X2)SEEQ0BM 2f
/$,21(0Z!R'4<HX#.*%5&e
d
endlalonde@torolab2.vnet.ibm.com (Glen Lalonde) (03/17/91)
I am looking for the gcc-as(gas) doc, if you know of a site which has archive mail server access and the doc please let me know. I tried to compile the Mac Minix mm with gcc, since mm is the smallest of the three OS parts. There is a two line assembler routine in head.s that was unresolved with I tried to bind. Thus I need to convert the macminix head.s to gcc-as format so I can get a gcc based .o to bind with. I don't think one would have any trouble compiling the fs though. For the kernel one would need to convert crtso.s to gcc-as format since it has a few mac hacks in it. Thus I need the gcc-as doc.
hyc@hanauma.jpl.nasa.gov (Howard Chu) (03/19/91)
In article <47880@nigel.ee.udel.edu> lalonde@torolab2.vnet.ibm.com (Glen Lalonde) writes: >I am looking for the gcc-as(gas) doc, if you know of a site which has >archive mail server access and the doc please let me know. >I tried to compile the Mac Minix mm with gcc, since mm is the smallest >of the three OS parts. There is a two line assembler routine in head.s >that was unresolved with I tried to bind. Thus I need to convert the >macminix head.s to gcc-as format so I can get a gcc based .o to bind >with. I don't think one would have any trouble compiling the fs though. >For the kernel one would need to convert crtso.s to gcc-as format since >it has a few mac hacks in it. Thus I need the gcc-as doc. You could have found enough to work with in less time than it took to post your article. Just compile a C file with the "-S" option to produce assembler source code instead of object code. The format is pretty simple to understand after you've seen an example. -- -- Howard Chu @ Jet Propulsion Laboratory, Pasadena, CA Disclaimer: How would I know, I just got here!
HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) (03/19/91)
gas uses a syntax called 'MIT syntax' just look at the output of gcc and you get a feeling for that syntax. C.v.W.