Files
2024-02-19 00:25:02 -05:00

927 lines
31 KiB
Plaintext

Subject: Linux-Development Digest #525
From: Digestifier <Linux-Development-Request@senator-bedfellow.MIT.EDU>
To: Linux-Development@senator-bedfellow.MIT.EDU
Reply-To: Linux-Development@senator-bedfellow.MIT.EDU
Date: Mon, 7 Mar 94 06:13:04 EST
Linux-Development Digest #525, Volume #1 Mon, 7 Mar 94 06:13:04 EST
Contents:
QUERY: Assembler Code Perversion (John R. Campbell)
Re: Amiga FileSystem, Anyone? (Joerg Mayer)
Mac FS, anyone? (Kayvan Sylvan)
Re: TTY overruns cost money. (Thomas G. McWilliams)
Some experiences with the Intel Pentium GCC (VIGNANI%MSIE03%CRFV2@CSPCLU.CSP.IT)
Re: YP or NIS for linux? (Jon Peatfield)
Re: pl15h I/O-prob sdb1 "mount -t msdos -o ..." (Karl Eichwalder)
----------------------------------------------------------------------------
From: soup@penrij.UUCP (John R. Campbell)
Subject: QUERY: Assembler Code Perversion
Date: Sun, 6 Mar 1994 10:25:01 GMT
I'm willing to bet that this is NOT the right group to post this Question
(but I will anyway).
I've been handed a sh*tload of MASM source code for the 386/486 (SCO UNIX)
and I need to convert it to a _REAL_ assembler (GAS on Linux, of course).
Anybody have any dirty tricks???
It generates that GodForsaken "x.out" format favored by MicroSloth which
NOBODY can disassemble (If only "sourcer" could generate REAL assembler).
I know this is foolish- but I'm expected to migrate this "forth nucleus"
to non-SCO systems and I need the "normal" assembler format to work from.
Please don't laugh- I'm trying to get the application running under linux
so I can be a lot happier... ...and even convince people that it's a
competent development (and perhaps production) platform.
--
John R. Campbell soup@penrij.UUCP
Speaker to Machines also: soup@sonosam.wisdom.bubble.org
When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl
Gun Control? Isn't that how we (as citizens) keep Congress in line?
------------------------------
From: jmayer@informatik.uni-kl.de (Joerg Mayer)
Subject: Re: Amiga FileSystem, Anyone?
Date: Sun, 6 Mar 1994 20:10:48 GMT
To add (or more likely repeat) some infos to this discussion I'll tell what is
done when a) an AMIGA and b) a PC reads/writes some data from/to disk.
AMIGA:
- write: get the whole trackdata (in decoded form). Overwrite those sectordata
you want to write. Now do MFM encoding for the whole track (note: this
encoding is totally incompatible with the MFM encoding done by PCs).
Write this data (called RAW data) to disk (only this last step gets
done by the controller).
-read: Read the whole track from disk. Decode the RAW data of the whole track
into sectors.
PC:
-write: Tell the diskcontroller which and how much of userdata to put where
on the disk. The diskcontroller waits until the corresponding sectors
(the AMIGA always works with whole tracks) are found and then (in
realtime) encodes and writes the data to disk.
-read: Works analogous to write.
In order for a PC to read a standard AMIGA disk, you'd have to tweak the PC's
controller to either pass on the data undecoded/unencoded or to read something
like one (or if neccessary several) very large blocks (consisting of several
AMIGA blocks) and try to reconstruct the original AMIGA data from the decoded
result (reencode) and then decode the whole stuff like the AMIGA does. I don't
know if this can be done, but even if, this can only be used to read data but
not to write it (you can't write the syncs).
Ciao ..
Jorg
===========
J"org Mayer (Student an der Universit"at Kaiserslautern)
e-mail : jmayer@informatik.uni-kl.de // PGPid: 0x2461E1
snail-mail: Marie-Juchacz-Str. 16 // 67663 Kaiserslautern // Germany
------------------------------
From: kayvan@satyr.Sylvan.COM (Kayvan Sylvan)
Subject: Mac FS, anyone?
Date: Mon, 7 Mar 1994 07:14:10 GMT
Following the tradition of the Amiga FS questions...
Does anyone know a way I can read a Mac 1.4MB floppy on Linux? My Mac
is an old Mac Plus (720K floppy drive) and it's connected to my Linux
box. If I can read files onto Linux, I can just suck them over the
line to the Mac.
Any ideas?
---Kayvan
--
| Kayvan Sylvan, Sylvan Associates, kayvan@satyr.Sylvan.COM, (408) 978-1407 |
| Consulting, Training, Development, SysAdmin, {BSD,SVr3,SVr4} Unix Systems |
| "Think Globally, Act Locally." "Only you can make your dreams come true." |
| Proud Dad of Katherine Yelena (born 8/8/89) & Robin Gregory (born 2/28/92) |
------------------------------
From: tgm@netcom.com (Thomas G. McWilliams)
Subject: Re: TTY overruns cost money.
Date: Mon, 7 Mar 1994 07:48:42 GMT
Nemosoft Unv. (nemosoft@void.tdcnet.nl) wrote:
: The significance of that being that even at that low speed, input
: overruns make my computer useless. The solution is to pull out the modem and
: thus hang up the connection, causing serial communication to stop :-(.
[ stuff deleted ]
: All serial ports are 16450s. Oh yeah: even with overruns, I don't loose
: data.
Your solution is to get a 16550 UART. It really is the most
straight forward and elegant path to solving your problem. And
hardware flow control is a "must" if your modem supports it
(make sure it is turned on ).
The 16550 really is a case of a modest technology providing a
lot of bang for the buck. The 16550's ability to buffer
characters before generating an interrupt truly improves system
throughput. It's about more than just not losing characters; it
is about improving system efficiency by reducing the cpu
overhead required to service a serial port.
The price is very reasonable. Stateside a 16550 will cost you
in the range of about 10 to 15 dollars. There is a popular
four-port serial card that offers the equivalent of four 16550's
on one serial card for about $100. And I've heard of a similar
card which is highly regarded and that is available in the UK
for a reasonable price. My suggestion is to "bite the bullet"
and upgrade your chips for a modest fee.
Thomas
tgm@netcom.com
------------------------------
From: VIGNANI%MSIE03%CRFV2@CSPCLU.CSP.IT
Subject: Some experiences with the Intel Pentium GCC
Date: 7 Mar 1994 03:27:19 -0500
Reply-To: VIGNANI%MSIE03%CRFV2@CSPCLU.CSP.IT
Hi Linuxers.
I got a copy of gcc-i2.4.0p (the pentium-optimizing gcc) from the Intel
ftp site (see below). I was intrigued by the possibility of getting better
performance from my 486 after reading the article "Optimizing Pentium Code"
in Dr.Dobb's Journal, Jan.94, p.40.
I compiled the Intel gcc and upgraded it to 2.4.5. Here's what I found:
- the 2.4.0 compiler seems to work quite well; I made some simple tests
and saw speed increments up to 25%. I even tried to compile some
_real_ code (gzip 1.2.4), but the attempt failed, I believe because of
the c library (I have 4.5.21). I think all should work with libc4.4.4.
- upgrading to gcc2.4.3 is no problem. The compiler compile itself well.
- upgrading to gcc2.4.5 seems to break something in the code generator;
the compiler does no more compile itself (it gets a fatal signal 6
while processing libgcc2). By ignoring the changes in config/i386 I
got at least a working compiler; but it crashes very often.
- I even tried to upgrade it to 2.5.8, but the code seemed seriously
broken.
I installed the 2.4.5 compiler under /usr/local and renamed gcc to
gcc5 to avoid confusion.
First, I optimized by hand some of the string functions in /linux/
include/linux/string.h, following the examples in the DDJ article;
then I tried to compile the kernel itself.
At first, it was not possible, because the Intel compiler complained
about an illegal constraint in 'asm' statements. I found the reason
browsing into gcc source code: the "S" constraint for the SI register
had been renamed by Intel to "e". This was not stated in the READMEs.
I had to replace the "S" constraints under conditional control, by
explicitly give a '-D__pentium__' parameter to gcc5 (the compiler
does not provide it).
The parameters I gave to gcc5 were: -O4 -m486 -D__pentium__.
Not all of the kernel compiles under gcc5, but when an object file is
produced, it usually works. I am going by small steps, and until now I
have compiled /linux/kernel (all ok but ptrace.c), /linux/mm and part of
/linux/drivers/char.
The resulting kernel is almost 20k bigger (4k compressed) and should be
faster (but it's harder to say without a profiler). This 'mixed' kernel
(partly gcc2.5.8, partly gcci2.4.5p) runs since two days on my machine
without any problem.
I recompiled also the ftape-0.9.9d module with -O4 -mpentium and
successfully made a tape backup.
Now IMHO: if you are interested to get a full working pentium-optimizing
compiler, you should wait for FSF to integrate the changes made by Intel.
But if you only need to squeeze the maximum performance out of a small
module into optimized assembly code, even the 2.4.0 compiler is worthwile.
It's a very helpful tool. At least until something better appears.
Alberto Vignani <vignani.crf@csp.it>
========================================================================
Here is my version of /linux/include/linux/string.h. I have replaced only
strcpy, strncpy and strcat, but you can get the feeling; lodsb-stosb are
slower on 486 than the full movb-inc-movb-inc.
I hope Someone Up High (in latitude... :-) ) will consider these changes.
========================================================================
#ifndef _LINUX_STRING_H_
#define _LINUX_STRING_H_
#include <linux/types.h> /* for size_t */
#ifndef NULL
#define NULL ((void *) 0)
#endif
#ifdef rcSI /* who knows? */
#error rcSI defined
#endif
#ifdef __pentium__
#define rcSI "e"
#else
#define rcSI "S"
#endif
/*
* This string-include defines all string functions as inline
* functions. Use gcc. It also assumes ds=es=data space, this should be
* normal. Most of the string-functions are rather heavily hand-optimized,
* see especially strtok,strstr,str[c]spn. They should work, but are not
* very easy to understand. Everything is done entirely within the register
* set, making the functions fast and clean. String instructions have been
* used through-out, making for "slightly" unclear code :-)
*
* Copyright (C) 1991, 1992 Linus Torvalds
*/
extern inline char * strcpy(char * dest,const char *src)
{
#ifdef __i486__
__asm__("\n1:\tmovb\t(%%esi),%%al\n"
"\tinc\t%%esi\n"
"\tmovb\t%%al,(%%edi)\n"
"\tinc\t%%edi\n"
"\torb\t%%al,%%al\n"
"\tjne\t1b\n"
:
:rcSI (src), "D" (dest)
:"ax","si","di","memory");
#else
__asm__("cld\n"
"1:\tlodsb\n\t"
"stosb\n\t"
"testb %%al,%%al\n\t"
"jne 1b"
: /* no output */
:rcSI (src),"D" (dest):"si","di","ax","memory");
#endif
return dest;
}
extern inline char * strncpy(char * dest,const char *src,size_t count)
{
#ifdef __i486__
__asm__("\n1:\tdecl\t%2\n"
"\tjs\t2f\n"
"\tmovb\t(%%esi),%%al\n"
"\tinc\t%%esi\n"
"\tmovb\t%%al,(%%edi)\n"
"\tinc\t%%edi\n"
"\torb\t%%al,%%al\n"
"\tjne\t1b\n"
"\trep\n"
"\tstosb\n"
"2:"
: /* no output */
:rcSI (src),"D" (dest),"c" (count)
:"si","di","ax","cx","memory");
#else
__asm__("cld\n"
"1:\tdecl %2\n\t"
"js 2f\n\t"
"lodsb\n\t"
"stosb\n\t"
"testb %%al,%%al\n\t"
"jne 1b\n\t"
"rep\n\t"
"stosb\n"
"2:"
: /* no output */
:rcSI (src),"D" (dest),"c" (count):"si","di","ax","cx","memory");
#endif
return dest;
}
extern inline char * strcat(char * dest,const char * src)
{
#ifdef __i486__
__asm__("cld\n"
"\trepne\n"
"\tscasb\n"
"\tdecl\t%1\n"
"1:\tmovb\t(%%esi),%%al\n"
"\tinc\t%%esi\n"
"\tmovb\t%%al,(%%edi)\n"
"\tinc\t%%edi\n"
"\torb\t%%al,%%al\n"
"\tjne\t1b\n"
: /* no output */
:rcSI (src),"D" (dest),"a" (0),"c" (0xffffffff)
:"si","di","ax","cx");
#else
__asm__("cld\n\t"
"repne\n\t"
"scasb\n\t"
"decl %1\n"
"1:\tlodsb\n\t"
"stosb\n\t"
"testb %%al,%%al\n\t"
"jne 1b"
: /* no output */
:rcSI (src),"D" (dest),"a" (0),"c" (0xffffffff):"si","di","ax","cx");
#endif
return dest;
}
extern inline char * strncat(char * dest,const char * src,size_t count)
{
__asm__("cld\n\t"
"repne\n\t"
"scasb\n\t"
"decl %1\n\t"
"movl %4,%3\n"
"1:\tdecl %3\n\t"
"js 2f\n\t"
"lodsb\n\t"
"stosb\n\t"
"testb %%al,%%al\n\t"
"jne 1b\n"
"2:\txorl %2,%2\n\t"
"stosb"
: /* no output */
:rcSI (src),"D" (dest),"a" (0),"c" (0xffffffff),"g" (count)
:"si","di","ax","cx","memory");
return dest;
}
extern inline int strcmp(const char * cs,const char * ct)
{
register int __res __asm__("ax");
__asm__("cld\n"
"1:\tlodsb\n\t"
"scasb\n\t"
"jne 2f\n\t"
"testb %%al,%%al\n\t"
"jne 1b\n\t"
"xorl %%eax,%%eax\n\t"
"jmp 3f\n"
"2:\tmovl $1,%%eax\n\t"
"jb 3f\n\t"
"negl %%eax\n"
"3:"
:"=a" (__res):"D" (cs),rcSI (ct):"si","di");
return __res;
}
extern inline int strncmp(const char * cs,const char * ct,size_t count)
{
register int __res __asm__("ax");
__asm__("cld\n"
"1:\tdecl %3\n\t"
"js 2f\n\t"
"lodsb\n\t"
"scasb\n\t"
"jne 3f\n\t"
"testb %%al,%%al\n\t"
"jne 1b\n"
"2:\txorl %%eax,%%eax\n\t"
"jmp 4f\n"
"3:\tmovl $1,%%eax\n\t"
"jb 4f\n\t"
"negl %%eax\n"
"4:"
:"=a" (__res):"D" (cs),rcSI (ct),"c" (count):"si","di","cx");
return __res;
}
extern inline char * strchr(const char * s,char c)
{
register char * __res __asm__("ax");
__asm__("cld\n\t"
"movb %%al,%%ah\n"
"1:\tlodsb\n\t"
"cmpb %%ah,%%al\n\t"
"je 2f\n\t"
"testb %%al,%%al\n\t"
"jne 1b\n\t"
"movl $1,%1\n"
"2:\tmovl %1,%0\n\t"
"decl %0"
:"=a" (__res):rcSI (s),"0" (c):"si");
return __res;
}
extern inline char * strrchr(const char * s,char c)
{
register char * __res __asm__("dx");
__asm__("cld\n\t"
"movb %%al,%%ah\n"
"1:\tlodsb\n\t"
"cmpb %%ah,%%al\n\t"
"jne 2f\n\t"
"movl %%esi,%0\n\t"
"decl %0\n"
"2:\ttestb %%al,%%al\n\t"
"jne 1b"
:"=d" (__res):"0" (0),rcSI (s),"a" (c):"ax","si");
return __res;
}
extern inline size_t strspn(const char * cs, const char * ct)
{
register char * __res __asm__("si");
__asm__("cld\n\t"
"movl %4,%%edi\n\t"
"repne\n\t"
"scasb\n\t"
"notl %%ecx\n\t"
"decl %%ecx\n\t"
"movl %%ecx,%%edx\n"
"1:\tlodsb\n\t"
"testb %%al,%%al\n\t"
"je 2f\n\t"
"movl %4,%%edi\n\t"
"movl %%edx,%%ecx\n\t"
"repne\n\t"
"scasb\n\t"
"je 1b\n"
"2:\tdecl %0"
:"=S" (__res):"a" (0),"c" (0xffffffff),"0" (cs),"g" (ct)
:"ax","cx","dx","di");
return __res-cs;
}
extern inline size_t strcspn(const char * cs, const char * ct)
{
register char * __res __asm__("si");
__asm__("cld\n\t"
"movl %4,%%edi\n\t"
"repne\n\t"
"scasb\n\t"
"notl %%ecx\n\t"
"decl %%ecx\n\t"
"movl %%ecx,%%edx\n"
"1:\tlodsb\n\t"
"testb %%al,%%al\n\t"
"je 2f\n\t"
"movl %4,%%edi\n\t"
"movl %%edx,%%ecx\n\t"
"repne\n\t"
"scasb\n\t"
"jne 1b\n"
"2:\tdecl %0"
:"=S" (__res):"a" (0),"c" (0xffffffff),"0" (cs),"g" (ct)
:"ax","cx","dx","di");
return __res-cs;
}
extern inline char * strpbrk(const char * cs,const char * ct)
{
register char * __res __asm__("si");
__asm__("cld\n\t"
"movl %4,%%edi\n\t"
"repne\n\t"
"scasb\n\t"
"notl %%ecx\n\t"
"decl %%ecx\n\t"
"movl %%ecx,%%edx\n"
"1:\tlodsb\n\t"
"testb %%al,%%al\n\t"
"je 2f\n\t"
"movl %4,%%edi\n\t"
"movl %%edx,%%ecx\n\t"
"repne\n\t"
"scasb\n\t"
"jne 1b\n\t"
"decl %0\n\t"
"jmp 3f\n"
"2:\txorl %0,%0\n"
"3:"
:"=S" (__res):"a" (0),"c" (0xffffffff),"0" (cs),"g" (ct)
:"ax","cx","dx","di");
return __res;
}
extern inline char * strstr(const char * cs,const char * ct)
{
register char * __res __asm__("ax");
__asm__("cld\n\t" \
"movl %4,%%edi\n\t"
"repne\n\t"
"scasb\n\t"
"notl %%ecx\n\t"
"decl %%ecx\n\t" /* NOTE! This also sets Z if searchstring='' */
"movl %%ecx,%%edx\n"
"1:\tmovl %4,%%edi\n\t"
"movl %%esi,%%eax\n\t"
"movl %%edx,%%ecx\n\t"
"repe\n\t"
"cmpsb\n\t"
"je 2f\n\t" /* also works for empty string, see above */
"xchgl %%eax,%%esi\n\t"
"incl %%esi\n\t"
"cmpb $0,-1(%%eax)\n\t"
"jne 1b\n\t"
"xorl %%eax,%%eax\n\t"
"2:"
:"=a" (__res):"0" (0),"c" (0xffffffff),rcSI (cs),"g" (ct)
:"cx","dx","di","si");
return __res;
}
extern inline size_t strlen(const char * s)
{
register int __res __asm__("cx");
__asm__("cld\n\t"
"repne\n\t"
"scasb\n\t"
"notl %0\n\t"
"decl %0"
:"=c" (__res):"D" (s),"a" (0),"0" (0xffffffff):"di");
return __res;
}
extern char * ___strtok;
extern inline char * strtok(char * s,const char * ct)
{
register char * __res;
__asm__("testl %1,%1\n\t"
"jne 1f\n\t"
"testl %0,%0\n\t"
"je 8f\n\t"
"movl %0,%1\n"
"1:\txorl %0,%0\n\t"
"movl $-1,%%ecx\n\t"
"xorl %%eax,%%eax\n\t"
"cld\n\t"
"movl %4,%%edi\n\t"
"repne\n\t"
"scasb\n\t"
"notl %%ecx\n\t"
"decl %%ecx\n\t"
"je 7f\n\t" /* empty delimeter-string */
"movl %%ecx,%%edx\n"
"2:\tlodsb\n\t"
"testb %%al,%%al\n\t"
"je 7f\n\t"
"movl %4,%%edi\n\t"
"movl %%edx,%%ecx\n\t"
"repne\n\t"
"scasb\n\t"
"je 2b\n\t"
"decl %1\n\t"
"cmpb $0,(%1)\n\t"
"je 7f\n\t"
"movl %1,%0\n"
"3:\tlodsb\n\t"
"testb %%al,%%al\n\t"
"je 5f\n\t"
"movl %4,%%edi\n\t"
"movl %%edx,%%ecx\n\t"
"repne\n\t"
"scasb\n\t"
"jne 3b\n\t"
"decl %1\n\t"
"cmpb $0,(%1)\n\t"
"je 5f\n\t"
"movb $0,(%1)\n\t"
"incl %1\n\t"
"jmp 6f\n"
"5:\txorl %1,%1\n"
"6:\tcmpb $0,(%0)\n\t"
"jne 7f\n\t"
"xorl %0,%0\n"
"7:\ttestl %0,%0\n\t"
"jne 8f\n\t"
"movl %0,%1\n"
"8:"
:"=b" (__res),"=S" (___strtok)
:"0" (___strtok),"1" (s),"g" (ct)
:"ax","cx","dx","di","memory");
return __res;
}
extern inline void * memcpy(void * to, const void * from, size_t n)
{
__asm__("cld\n\t"
"movl %%edx, %%ecx\n\t"
"shrl $2,%%ecx\n\t"
"rep ; movsl\n\t"
"testb $1,%%dl\n\t"
"je 1f\n\t"
"movsb\n"
"1:\ttestb $2,%%dl\n\t"
"je 2f\n\t"
"movsw\n"
"2:\n"
: /* no output */
:"d" (n),"D" ((long) to),rcSI ((long) from)
: "ecx","edx","edi","esi","memory");
return (to);
}
extern inline void * memmove(void * dest,const void * src, size_t n)
{
if (dest<src)
__asm__("cld\n\t"
"rep\n\t"
"movsb"
: /* no output */
:"c" (n),rcSI (src),"D" (dest)
:"cx","si","di");
else
__asm__("std\n\t"
"rep\n\t"
"movsb\n\t"
"cld"
: /* no output */
:"c" (n),
rcSI (n-1+(const char *)src),
"D" (n-1+(char *)dest)
:"cx","si","di","memory");
return dest;
}
extern inline int memcmp(const void * cs,const void * ct,size_t count)
{
register int __res __asm__("ax");
__asm__("cld\n\t"
"repe\n\t"
"cmpsb\n\t"
"je 1f\n\t"
"movl $1,%%eax\n\t"
"jb 1f\n\t"
"negl %%eax\n"
"1:"
:"=a" (__res):"0" (0),"D" (cs),rcSI (ct),"c" (count)
:"si","di","cx");
return __res;
}
extern inline void * memchr(const void * cs,char c,size_t count)
{
register void * __res __asm__("di");
if (!count)
return NULL;
__asm__("cld\n\t"
"repne\n\t"
"scasb\n\t"
"je 1f\n\t"
"movl $1,%0\n"
"1:\tdecl %0"
:"=D" (__res):"a" (c),"D" (cs),"c" (count)
:"cx");
return __res;
}
extern inline void * memset(void * s,char c,size_t count)
{
__asm__("cld\n\t"
"rep\n\t"
"stosb"
: /* no output */
:"a" (c),"D" (s),"c" (count)
:"cx","di","memory");
return s;
}
#undef rcSI
#endif
==========================================================================
And here is the official Intel announce:
==========================================================================
GCC WITH INTEL ENHANCEMENTS FOR THE PENTIUM CPU/INTEL ARCHITECTURE (13 Jan 94)
==============================================================================
This file describes the GNU-C compiler with intel enhancements for the
intel Pentium cpu and other members of the Intel Architecture (IA).
The compiler sources (gcc-i2.4.0p.tar.Z) and this file (README.iGCC)
can be ftp'ed from:
anonymous@aurora.intel.com:/pub/intel_arch/gnu/compiler/ (143.185.65.2)
DISCLAIMER
==========
Intel disclaims all warranties with regard to this software, including all
implied warranties of merchantibility and fitness for a particular purpose.
in no event shall Intel be liable for any special, indirect or consequential
damages or any damages whatsoever resulting from loss of use, data or profits,
whether in an action of contract, negligence or other tortuous action, arising
out of or in connection with the use or performance of this software.
DESCRIPTION
===========
This GNU-C compiler is a technology demo which includes the sources for GNU-C
2.4.0 and modifications / enhancements done in intel.
Sources: There are many changes in compiler sources, machine dependent and
independent, they are marked with "intel1" or "intel2" so one can easily
identify them (no new files were added to the GNU-C release).
Performance: we measured ~25% improvement for SPECint92 on a Pentium machine,
there is a great improvement for other IA implementations too.
Distribution: This compiler is distributed under the FSF copyleft copyright
notice which is included in every file.
All these modifications were sent to the Free Software Foundation and we hope
that they will find their way into FSF source base.
Testing: The compiler was tested on SPEC92 benchmarks, PLUM-HALL 4.0 test
suite and many other programs, the previous version (based on 2.3) compiled
successfully a Mach MK and it's servers. I don't think the cc1plus was tested.
Support: No, remember that this is only a technology demo and should be treated
as such, this project no longer exists so please don't send bugs.
General comments about GCC for IA and optimizations for IA are more than
welcomed.
INSTALLATION
============
The compiler can be configured to default generate pentium optimized code:
e.g. ' > ./configure pentium-sysv4 ' will make pentium the default target
cpu (as done with i386/i486) with a svr4 os.
FLAGS
=====
Two new machine dependent flags were added to GCC :
`-mpentium' : for generating code optimized for the pentium cpu.
`-mblend' : for generating code reasonably optimized for all the IA family
without penalizing any member of the family
(blend not used in this version).
The usual -O0, -O, -O2 were changed, the new scheme added new flags for -O
and -O2, new -Ox options were added: -O3 and -O4.
-O:
Gcc's flags +
-fopt-reg-use : Optimize usage of registers for memory addresses.
-freduce-index-givs : Try to treat index terms of addresses as reducible
mem givs.
-O3:
Gcc's -O2 flags + gcc's -fomit-frame-pointer + gcc's -finline-functions+
-fcompare-elim : Do compare elimination.
-fsign-extension-elim : Do sign-extension elimination.
-fjump-back : In optimization of loops treats jumps backwards as
not nullifying optimization opportunities.
-floop-after-global : After reload try to optimize usage of spill slots
in loops.
-fall-mem-givs : Do reduce all the mem address givs.
-fpeep-spills : After reload try to replace spill slots with
equivalent registers.
-fcopy-prop : Do loop copy propagation.
-flift-stores : Try to lift memory disambiguated memory operands that
are stored to in a loop into a register for the
duration of the loop.
-fruntime-lift-stores : As above but do the disambiguation at runtime.
i.e. there will be two copies of the loop, one
disambiguated one not, And the decision of which one
to run will be made at runtime.
-fdo-offload : Move stack registers that will be compared for
equality off, the stack before the comparison.
-fopt-reg-stack : Optimize usage of stack registers from the stack.
-fcorrect-cse-mistakes : cse is sometimes detrimental - see flow.c .
-fspl : Do a mini software pipelining on stack registers.
-fopt-jumps-out : Try aggressive changing of jumps taken to jumps not
taken.
-freplace-mem : Try to replace memory operands with equivalent
registers in first pass of loop optimize.
-freplace-stack-mem : Try to replace memory operands with equivalent stack
registers in first pass of loop optimize.
-finterleave-stack-non-stack : Use the first pass of the scheduler to rearrange
between insns that reference stack registers and
those that don't but not amongst themselves.
-freg-reg-copy-opt : After reload if a register is marked dead at a copy
into another register - see if the other register can
be used in the first place Thereby eliminating the
copy.
-fpush-load-into-loop : Try to push loads back into loops if the loaded
register has been spilled.
-frecombine : If the riscified instruction has not changed it's
place in scheduling then recombine it into a cisc
instruction.
-freplace-reload-regs : Try to use available registers so that a memory
operand that is reloaded will be reloaded into the
same register. This helps loop_after_global.
-frisc-mem-dest : A destination that was riscified should stay that way.
-O4:
All of the above + gcc's scheduling +
-fswap-for-agi : Allow scheduler to try to swap two instructions when
the first increments a register by a constant and
the second uses that register as a base.
-frisc : After reload use available registers to load memory
operands into them and use the register instead of
the memory operand.
-frisc-const : After reload use available registers to load
CONST_INTs into them and then store the register
instead of the CONST_INT.
-fschedule-stack-reg-insns : Use the first pass of the scheduler to rearrange
between insns that reference stack registers.
Some of these flags also have a -fno- switch and some of these are turned on/off
in an obscured way dependent on the target cpu.
===========================================================================
Jonathan Beimel Phone: (011)+972-4-65-5904
Email: jbeimel@iil.intel.com Fax : (011)+972-4-65-5674
------------------------------
From: jp107@amtp.cam.ac.uk (Jon Peatfield)
Subject: Re: YP or NIS for linux?
Date: Sat, 5 Mar 1994 23:07:11 GMT
> There are already two implementations:
> yp-linux
> NYS
> The first one can be found in any Slackware source archive, ...
Well having looked through the nearest 2 slackware-mirror sites to me
I've not found any mention of yp-linux or any other yp stuff in
slackware. Am I missing something here?
I could find one site with yp-linux:
faui43.informatik.uni-erlangen.de:/mounts/epix/public/pub/Linux/LOCAL/yp/yp-linux.tar.gz
but it seemed to be pretty old, libc-4.4.2 etc...
I seem to remember that the person who did the BSD server that
yp-linux is a port of updated it to use file formats compatible with
the sun programs, does anyone know if those got ported to Linux too?
Also I seem to remember a posting talking about a ypserver, any
locations for that?
-- Jon Peatfield
--
Jon Peatfield, Computer Officer, the DAMTP, University of Cambridge
Telephone: (+44 223) 3-37852 Mail: J.S.Peatfield@amtp.cam.ac.uk
PP breaks RFC-822 when forwarding SMTP->SMTP mail. PP: Just say NO.
------------------------------
From: karl@pertron.central.de (Karl Eichwalder)
Subject: Re: pl15h I/O-prob sdb1 "mount -t msdos -o ..."
Date: Sun, 6 Mar 1994 09:39:26 GMT
Karl Eichwalder (karl@pertron.central.de) wrote:
> Until yesterday special mount options work w/o any prob, e.g.:
> # mount -t msdos -o conv=auto,uid=405,gid=50,umask=027 /dev/sdb1 /mnt/sq
> But now user 405 could not copy files from the Syquest medium anymore (with
> this mount options the same for root).
With pl15j still the same.
BTW `mount mount -t msdos /dev/sdb1 /mnt/sq' works alright, but not this -o
switch.
Configuration:
386DX33, Adaptec 1542B, Quantum LPS 240, Syquest 44MB, NE2000 clone, ET4000.
pl15j, libc.so.4.4.4, ld.so.1.4. (mount --version: Linux bootutils 0.99.14
(=linux-util-1.4,tar.gz)).
--
| Internet : keichwa@gwdg.de
| : karl@pertron.central.de
Karl Eichwalder | Fido : 2:2437/210.55
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: Linux-Development-Request@NEWS-DIGESTS.MIT.EDU
You can send mail to the entire list (and comp.os.linux.development) via:
Internet: Linux-Development@NEWS-DIGESTS.MIT.EDU
Linux may be obtained via one of these FTP sites:
nic.funet.fi pub/OS/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development Digest
******************************