🚀 go-pugleaf

jkh@meepmeep.pcs.com (Jordan K. Hubbard) writes:
----^
    sehr niedlicher Name !!

>                         Final Announcement
>                         ------------------

>			       ENDLICH !

>			    GCC auf CADMUS


   Also zuerst einmal: Grossartig, Bravo , Toll, (endlich..)
   Grosses Lob an die Jungs von PCS !

>	     Folgende Highlights erzwingen geradezu die Verwen-
>	     dung  der  GNU  C  Entwicklungsumgebung  fuer Ihre
>	     naechsten groesseren (!!!)  Softwareprojekte:


>	     -    Voll ANSI C oder K&R C kompatibel (Option)

>	     -    Ojektmodul-   (.o),   Aufrufkonvention    und
>		  Bibliotheksformat    Sun-3   kompatibel   (zu
>		  testen)

	Und genau da liegt das Problem: Sun-3 kompatibel bedeutet
	ja wohl, dass die Object-Files im BSD-Format mit dbx-Debuggerinfos
	vorliegen, der PCS-cc aber COFF erzeugt. Ergo sind die Objects nicht
	miteinander verwendbar, so dass einige Libraries ebenfalls mit dem 
	GCC nicht mehr verwendbar sind. Aus der Ankuendigung entnehme ich,
	dass die libc nicht durch dieses 'robotusin'-Programm konvertiert 
	wurden, sondern alles neu kompiliert wurde (was an sich auch gut ist).
	Die Frage heisst also: Was machen wir mit unseren Bibliotheken, wie z.B.	libX aus dem Xwindows-Paket? Sind die ebenfalls dabei oder als 
	gnu-isiertes erhaeltlich oder kann man die durch robutussin oder 
	aehnlich erzeugen? Weiter gefragt: Welche a.out-Format 
	erzeugt der GNU-ld, ist es das alte V.2/07 von den 16bit-9200 
	CADMUSsen oder ist es das ominoese 'encapsulated COFF' ?

	Kurzum, zwei verschiedene Bibliothekssaetze auf dem Rechner zu haben
	halte ich nicht fuer so ideal. Ich persoenlich kaempfe naemlich seit 
	mehreren Wochen an einer Portierung von gcc und g++ auf eine 
	Nixdorf Targon31 (gcc laeuft, g++ ist noch nicht perfekt). Da es
	bei dem sgs-Assembler vom SystemV/68 sehr schwierig ist, freie Zeichen
	fuer die gdb+-Symbole zu finden, habe ich in letzter Zeit ernsthaft mit
	dem Gedanken gespielt, den GNU-Assembler gas mit COFF auszuruesten.
	(Wie ich eben beschlossen habe, kann man den sgs-Assembler aufgrund 
	seiner idiotischen Regeln fuer Identifier nur hirnverbrannt 
	bezeichnen..) Waere also interessant zu wissen, ob es sowas gibt oder
	jemand schon seinen Grips daran vergeudet hat.


				Weiter so, PCS !

					Michael Joosten
					joost@rubmez.uucp

	Ruhr Universitaet Bochum, Mikroelektronikzentrum & Lehrstuhl fuer
		elektronische Bauelemente 

>>jkh@meepmeep.pcs.com (Jordan K. Hubbard) writes:
>----^
>    sehr niedlicher Name !!

Danke, aber es ist nicht mein Fehler! Es ist auch Quatsch, weil unsere
Maschine nicht so schnell ist wie der Roadrunner. Mehr wie Wily (stuertzt
oefters ab).

>   Also zuerst einmal: Grossartig, Bravo , Toll, (endlich..)

Furtz.. Ruelps.. Kotz.. Ja ja.. :-)

>	Und genau da liegt das Problem: Sun-3 kompatibel bedeutet
>	ja wohl, dass die Object-Files im BSD-Format mit dbx-Debuggerinfos
>	vorliegen, der PCS-cc aber COFF erzeugt. Ergo sind die Objects nicht
>	miteinander verwendbar, so dass einige Libraries ebenfalls mit dem 

Stimmt. Aber, aechtz... Ok, Zeit fuer Englisch! 

Sun3 compatability was not the point of the exercise, though this was
an interesting side-effect. The main problem is that PCS cc has no assembler
whatsoever and goes directly to object code. This might have seemed like a
good idea at the time, but it forced us to use GAS which does not support COFF
directly. We solve the library problem by distributing all-new libraries
with the GCC compiler (I am sorry that we forgot to mention this important
fact in our original article). The R4 X Windows release will include GCC
libraries for all the X libs as well. This will actually be very easy for
us since we now use only gcc internally (supporting libaries for the original
cc may be a small problem, however.. :-).

>	aehnlich erzeugen? Weiter gefragt: Welche a.out-Format 
>	erzeugt der GNU-ld, ist es das alte V.2/07 von den 16bit-9200 
>	CADMUSsen oder ist es das ominoese 'encapsulated COFF' ?

Encapsulated COFF. This is not wonderful, but it does have a very large
advantage when using gdb on large executables. Gdb must load *all* symbols
from a COFF file before starting up which can take up to 5-10 minutes
for a really large (>3MB) executable like the X color server, or Kyoto Common
Lisp. With Encapsulated COFF, the symbol information is in DBX format
which can be loaded by gdb "incrementally" (e.g. as needed). This makes
startup time about 20 times faster. Our server developers would have gone
insane about 3 months ago if it hadn't been for this feature (some might
rightly point out that they're already insane, but this is beside the point).

>	Kurzum, zwei verschiedene Bibliothekssaetze auf dem Rechner zu haben
>	halte ich nicht fuer so ideal. Ich persoenlich kaempfe naemlich seit 
>	mehreren Wochen an einer Portierung von gcc und g++ auf eine 
>	Nixdorf Targon31 (gcc laeuft, g++ ist noch nicht perfekt). Da es

The solution is quite simple: Don't use the original cc at all and remove
all the old COFF libraries! This is what I have done on my home machine
and it works fine. I have yet to find a program (that isn't broken) that
won't compile under gcc but will under cc. I've also re-written all the
object-format-specific routines in GNU and KCL that need to directly read
or write object files (like KCL's fasload() and faslink() or GNU emacs's
unexec()) to use COFF encapsulation, so there's no problem there either.
About the only thing we have yet to compile under gcc is the UNIX kernel
itself, and we're working on that right now.

Right now, to sumarize it all, what you'll get from us on the GCC tape
is:

GCC 1.37.1
G++ 1.37.1 (new) + libg++ 1.37

GAS 1.35 + GLD and all the binutils (size, strip, ar, nm, etc..), with a few
bugs fixed, for Coff encapsulation.

GDB 3.5 for COFF Encapsulated binaries.

All new system libraries. Possibly all new X (R3) libraries as well, I have
to check what out licensing policy is with this. If it's not a problem,
we'll include them too.

Documentation in German (there's already plenty in English).

>				Weiter so, PCS !

We try...

			Viele Gruesse,

				Jordan Hubbard
--
			PCS Computer Systeme GmbH, Munich, West Germany
	UUCP:		pyramid!pcsbst!jkh jkh@meepmeep.pcs.com
	EUNET:		unido!pcsbst!jkh
	ARPA:		jkh@violet.berkeley.edu or hubbard@decwrl.dec.com

jkh@meepmeep.pcs.com (Jordan K. Hubbard) writes:

>The solution is quite simple: Don't use the original cc at all and remove
>all the old COFF libraries! This is what I have done on my home machine
>and it works fine. I have yet to find a program (that isn't broken) that
>won't compile under gcc but will under cc. I've also re-written all the
>object-format-specific routines in GNU and KCL that need to directly read
>or write object files (like KCL's fasload() and faslink() or GNU emacs's
>unexec()) to use COFF encapsulation, so there's no problem there either.
>About the only thing we have yet to compile under gcc is the UNIX kernel
>itself, and we're working on that right now.
Das ist ja ganz nett, aber was ist mit den shared libraries?
Meine Maschinen halten sich mit 8MB nur mit Ach und Krach, weil wir 
die shared libraries benutzen koennen. 

Und was ist mit Fortran? Da geht ja wohl dann garnix! Wenn man Fortran
und/oder andere Sprachen auch noch braucht, dann kann man auch nicht einfach
die alten libs wegschmeissen! 

Support kann man wohl dann auch ganz vergessen, bei der normalen COFF-lib
kann ich wenigstens hoffen dass die Fehlermeldung was bewirkt!

Gruss, Klaus
Klaus Steinberger               Beschleunigerlabor der TU und LMU Muenchen
Phone: (+49 89)3209 4287        Hochschulgelaende, D-8046 Garching, West Germany
BITNET:  K2@DGABLG5P            Internet: k2@charly.bl.physik.tu-muenchen.de

Das ist ja ganz nett, aber was ist mit den shared libraries?
Meine Maschinen halten sich mit 8MB nur mit Ach und Krach, weil wir 
die shared libraries benutzen koennen. 

Unfortunately, gcc still does not support position independent code (-pic),
making shared libraries difficult. Soon. Until then, we'd be happy to
sell you another 8mb memory board. Just call our sales dept! :-)

>Und was ist mit Fortran? Da geht ja wohl dann garnix! Wenn man Fortran
>und/oder andere Sprachen auch noch braucht, dann kann man auch nicht einfach

Ja ja, ok, nur die Ruhe! :-)

I guess I should have said "If you're not interfacing any other languages."
We've dealt with this problem also, by the way. The PCS COFF GAS should be
released back to the FSF sometime next week or so. We will then begin working
on a special "dual gcc" that will produce COFF or COFF encapsulated output.
We don't want to give up COFF Encapsulation totally since debugging will
then be much slower (as I mentioned in my last article) and we won't be
able to incrementally load (ld -A) object files into running programs.

Good enough?

				Hang loose, dudes.

					Jordan
--
			PCS Computer Systeme GmbH, Munich, West Germany
	UUCP:		pyramid!pcsbst!jkh jkh@meepmeep.pcs.com
	EUNET:		unido!pcsbst!jkh
	ARPA:		jkh@violet.berkeley.edu or hubbard@decwrl.dec.com

jkh@meepmeep.pcs.com (Jordan K. Hubbard) writes:
>[...]
>Right now, to sumarize it all, what you'll get from us on the GCC tape
>is:

>GCC 1.37.1
>G++ 1.37.1 (new) + libg++ 1.37

>GAS 1.35 + GLD and all the binutils (size, strip, ar, nm, etc..), with a few
>bugs fixed, for Coff encapsulation.

>GDB 3.5 for COFF Encapsulated binaries.

>All new system libraries. Possibly all new X (R3) libraries as well, I have
>to check what out licensing policy is with this. If it's not a problem,
>we'll include them too.

>Documentation in German (there's already plenty in English).

Probably most of that stuff will be available via anon FTP from TU Muenchen
soon, I have not yet decided on which machine to put it.  I'm doing most of
my development work with gcc from Jordan now, works great.  Using gdb under
emacs is really nice.

Nochmal in Deutsch:

Also, wahrscheinlich wirds ab demnaechst einen anonymous FTP account hier
geben, von dem man sich das meiste von Jordans Programmen holen kann
(wahrscheinlch alles GNU-Zeugs, aber nicht die 11.3 Libs)  Ich weiss nur
noch nicht genau, auf welcher Kiste ich den Server laufen lassen werde.
Ich benutze den Gcc jetzt schon seit einiger Zeit (und auch fuer groessere
Dinge), macht einen relativ stabilen Eindruck, und Debuggen mit gdb ist
einfach himmlisch im Vergleich zu sdb.

>>				Weiter so, PCS !

>We try...

We hope you do ... :-)

>			Viele Gruesse,

>				Jordan Hubbard

\Bernhard.
--
Bernhard Schneck        Internet: B.Schneck@E17.Physik.TU-Muenchen.DE
TU Muenchen Physik E17  X.400   : S=schneck,OU=lan,OU=informatik,      
8046 Garching                     PRMD=tu-muenchen,ADMD=dbp,C=de
West Germany            BitNET  : schneck@dgablg5p
--
"There is no problem so big that it cannot be run away from"
                                                        Illusions, Richard Bach
Bernhard Schneck        Internet: B.Schneck@E17.Physik.TU-Muenchen.DE
TU Muenchen Physik E17  X.400   : S=schneck,OU=lan,OU=informatik,      
8046 Garching                     PRMD=tu-muenchen,ADMD=dbp,C=de
West Germany            BitNET  : schneck@dgablg5p