Linux-Development-Sys Digest #905, Volume #6 Mon, 28 Jun 99 22:14:28 EDT
Contents:
Re: Why not C++ (Johan Kullstam)
Re: sources for the empeg car player? (Michael Hirsch)
Re: Need a.out compiler ("Aaron Thompson")
Re: File Allocation Tables (Adam Brinley Codd)
Re: help me please, URGENT (John McKown)
Re: Can Linux Boot and Run without a BIOS? (Jim Robertson)
Re: PTHREADS kernel/user level threading? (Michael Hirsch)
Call for Papers for OSDI 2000-USENIX Operating Systems Symposium (Jennifer Radtke)
Re: PTHREADS kernel/user level threading? (David Wragg)
Re: Need help porting DOS app that uses parallel port (Part II) (Philipp Thomas)
Re: Why not C++ (Christopher Browne)
Re: File max size (Konrad Mieredorff)
Re: Filesize larger than 2 GB on Intel machines an Linux 2.0.36 (Christopher Browne)
Re: Why not C++ (Nathan Myers)
Re: Filesize larger than 2 GB on Intel machines an Linux 2.0.36 (Christopher Browne)
Re: Proposal For New Windowing software (Christopher Browne)
Re: Ultimate OS (Konrad Mieredorff)
Re: tcp port no.s vs. processes (Sudip Sarbajna)
Re: Why not C++ (Nathan Myers)
----------------------------------------------------------------------------
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
From: Johan Kullstam <[EMAIL PROTECTED]>
Date: 28 Jun 1999 18:51:12 -0400
[EMAIL PROTECTED] writes:
> In comp.os.linux.development.system Nathan Myers <[EMAIL PROTECTED]> wrote:
> : [EMAIL PROTECTED] wrote in message ...
> :>In comp.os.linux.development.system Nathan Myers
> :>
> :>: Enough generalities. Take for example Egcs. C and C++, same code
> :>: generator, same optimizer. The last time you tried g++ was years
> :>: and years ago. It's time to look again.
> :>
> :>Using the latest egcs (from CVS) to compile a C program, with options
> :>'-fno-exceptions -fno-rtti -O2', the C assembler output is still
> :>smaller (in terms of # of instructions, not symbol length) while
> :>producing the same results.
>
> : Unsupported assertion noted (again).
>
> : What source code?
> : How _much_ smaller (if any)?
> : How _much_ faster (if any)?
>
> : Without proof, this is just more FUD.
>
>
> You cannot find a random C program and compile it yourself with g++?
> Who is FUD'ing now?
>
> A simple program is listed below. I have used different setting per a
> suggestion in this thread:
>
> $ cat > c.c
> $ cp c.c c.cc
> $ /usr/local/egcs/bin/gcc -O2 -fomit-frame-pointer -S c.c
> $ /usr/local/egcs/bin/g++ -O2 -fomit-frame-pointer -S cc.cc
> $ diff -u c.s cc.s | wc -l
> 134
>
> $ /usr/local/egcs/bin/g++ -O2 -fomit-frame-pointer -fno-rtti -S cc.cc
> $ diff -u c.s cc.s | wc -l
> 134
>
> $ /usr/local/egcs/bin/g++ -O2 -fomit-frame-pointer -fno-exceptions -S cc.cc
> $ diff -u c.s cc.s | wc -l
> 66
>
> $ /usr/local/egcs/bin/g++ -O2 -fomit-frame-pointer -fno-rtti -fno-exceptions
>-S cc.cc
> $ diff -u c.s cc.s | wc -l
> 66
>
> The linecount for each diff is 95% new instructions added by the C++ compiler.
>
> Jeff
>
>
> /**********************************************************************/
>
> #include <stdio.h>
>
> long boing (long foo)
> {
> if (foo > 1)
> return (foo * boing(foo - 1));
>
> return 1;
> }
>
>
> int main()
> {
> printf("hello world boing %ld\n", boing(42));
> }
the above is a big crock.
i took the above code and put it into the file foo.c. i ran egcs on
in it [1]
gcc -O2 -fomit-frame-pointer -S -fverbose-asm foo.c
g++ -O2 -fomit-frame-pointer -S -fverbose-asm foo.c
here is the assembly out of the C compile
==========================================================================
.file "foo.c"
.version "01.01"
# GNU C version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) (i386-redhat-linux)
compiled by GNU C version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release).
# options passed: -march=pentiumpro -O2 -fomit-frame-pointer -fverbose-asm
# options enabled: -fdefer-pop -fomit-frame-pointer -fcse-follow-jumps
# -fcse-skip-blocks -fexpensive-optimizations -fthread-jumps
# -fstrength-reduce -fpeephole -fforce-mem -ffunction-cse -finline
# -fkeep-static-consts -fcaller-saves -fpcc-struct-return -fgcse
# -frerun-cse-after-loop -frerun-loop-opt -fschedule-insns2 -fcommon
# -fverbose-asm -fgnu-linker -fregmove -foptimize-register-move
# -fargument-alias -m80387 -mhard-float -mno-soft-float -mieee-fp
# -mfp-ret-in-387 -mschedule-prologue -mcpu=pentiumpro -march=pentiumpro
gcc2_compiled.:
.text
.align 4
.globl boing
.type boing,@function
boing:
pushl %ebx
movl 8(%esp),%ebx
cmpl $1,%ebx
jle .L17
leal -1(%ebx),%eax
pushl %eax
call boing
imull %eax,%ebx
movl %ebx,%eax
addl $4,%esp
jmp .L16
.p2align 4,,7
.L17:
movl $1,%eax
.L16:
popl %ebx
ret
.Lfe1:
.size boing,.Lfe1-boing
.section .rodata
.LC0:
.string "hello world boing %ld\n"
.text
.align 4
.globl main
.type main,@function
main:
pushl $42
call boing
pushl %eax
pushl $.LC0
call printf
addl $12,%esp
ret
.Lfe2:
.size main,.Lfe2-main
.ident "GCC: (GNU) egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)"
==========================================================================
and here is the C++ output
==========================================================================
.file "foo.c"
.version "01.01"
# GNU C++ version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) (i386-redhat-linux)
compiled by GNU C version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release).
# options passed: -march=pentiumpro -O2 -fomit-frame-pointer -fverbose-asm
# options enabled: -fdefer-pop -fomit-frame-pointer -fcse-follow-jumps
# -fcse-skip-blocks -fexpensive-optimizations -fthread-jumps
# -fstrength-reduce -fpeephole -fforce-mem -ffunction-cse -finline
# -fkeep-static-consts -fcaller-saves -fpcc-struct-return -fgcse
# -frerun-cse-after-loop -frerun-loop-opt -fschedule-insns2 -fexceptions
# -fcommon -fverbose-asm -fgnu-linker -fregmove -foptimize-register-move
# -fargument-alias -m80387 -mhard-float -mno-soft-float -mieee-fp
# -mfp-ret-in-387 -mschedule-prologue -mcpu=pentiumpro -march=pentiumpro
gcc2_compiled.:
.globl __throw
.text
.align 4
.globl boing__Fl
.type boing__Fl,@function
boing__Fl:
.LFB1:
pushl %ebx
.LCFI0:
movl 8(%esp),%ebx
cmpl $1,%ebx
jle .L167
leal -1(%ebx),%eax
pushl %eax
.LCFI1:
call boing__Fl
imull %eax,%ebx
movl %ebx,%eax
addl $4,%esp
.LCFI2:
jmp .L166
.p2align 4,,7
.L167:
movl $1,%eax
.L166:
popl %ebx
ret
.LFE1:
.Lfe1:
.size boing__Fl,.Lfe1-boing__Fl
.section .rodata
.LC0:
.string "hello world boing %ld\n"
.text
.align 4
.globl main
.type main,@function
main:
.LFB2:
pushl $42
.LCFI3:
call boing__Fl
pushl %eax
.LCFI4:
pushl $.LC0
.LCFI5:
.LCFI6:
call printf
addl $12,%esp
.LCFI7:
xorl %eax,%eax
ret
.LFE2:
.Lfe2:
.size main,.Lfe2-main
.section .eh_frame,"aw",@progbits
__FRAME_BEGIN__:
.4byte .LLCIE1
.LSCIE1:
.4byte 0x0
.byte 0x1
.byte 0x0
.byte 0x1
.byte 0x7c
.byte 0x8
.byte 0xc
.byte 0x4
.byte 0x4
.byte 0x88
.byte 0x1
.align 4
.LECIE1:
.set .LLCIE1,.LECIE1-.LSCIE1
.4byte .LLFDE1
.LSFDE1:
.4byte .LSFDE1-__FRAME_BEGIN__
.4byte .LFB1
.4byte .LFE1-.LFB1
.byte 0x4
.4byte .LCFI0-.LFB1
.byte 0xe
.byte 0x8
.byte 0x83
.byte 0x2
.byte 0x4
.4byte .LCFI1-.LCFI0
.byte 0xe
.byte 0xc
.byte 0x2e
.byte 0x4
.byte 0x4
.4byte .LCFI2-.LCFI1
.byte 0xe
.byte 0x8
.byte 0x2e
.byte 0x0
.align 4
.LEFDE1:
.set .LLFDE1,.LEFDE1-.LSFDE1
.4byte .LLFDE3
.LSFDE3:
.4byte .LSFDE3-__FRAME_BEGIN__
.4byte .LFB2
.4byte .LFE2-.LFB2
.byte 0x4
.4byte .LCFI3-.LFB2
.byte 0xe
.byte 0x8
.byte 0x2e
.byte 0x4
.byte 0x4
.4byte .LCFI4-.LCFI3
.byte 0xe
.byte 0xc
.byte 0x2e
.byte 0x8
.byte 0x4
.4byte .LCFI5-.LCFI4
.byte 0xe
.byte 0x10
.byte 0x2e
.byte 0xc
.byte 0x4
.4byte .LCFI6-.LCFI5
.byte 0x2e
.byte 0x8
.byte 0x4
.4byte .LCFI7-.LCFI6
.byte 0xe
.byte 0x4
.byte 0x2e
.byte 0x0
.align 4
.LEFDE3:
.set .LLFDE3,.LEFDE3-.LSFDE3
.ident "GCC: (GNU) egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)"
==========================================================================
if you go through the assembly and compare instructions you'll see
that although the C++ assembly has a lot more labels than the C
assembly it is *exactly the same op-codes*.[1]
this example is too trivial to elicit any difference. still C passes
through cc1 and C++ passes through cc1plus. a more complex case could
show a difference. i shall investigate further.
[1] i've hacked my compiler spec to send -march=pentiumpro by
default. the verbose assembly reflects this.
[2] except for the `xor eax,eax' at the end of the C++ to
return 0 from main. the original C code was a bit shoddy on this
point since it promise to return an int but failed to set the
return value. i do not hold this against C++.
--
J o h a n K u l l s t a m
[[EMAIL PROTECTED]]
Don't Fear the Penguin!
------------------------------
From: Michael Hirsch <[EMAIL PROTECTED]>
Subject: Re: sources for the empeg car player?
Date: 28 Jun 1999 18:32:13 -0400
Peter Gavin <[EMAIL PROTECTED]> writes:
> I've emailed them, asking where I could get it.. I'll post an update
> when (if) he emails me back.
There are a bunch of these embedded system type boxes. empeg, netgem,
and TeeVO (or however it's spelled) to name three. I can't find
sources for any of the and I haven't gotten responses to my email,
yet.
--Michael
> Michael Hirsch wrote:
> >
> > As I recall, the guy who built the empeg (www.empeg.com) car player
> > built a custom MB and then put a custom version of linux on it. Since
> > it is now shipping, the sources to the GPLed parts of the player must
> > be available.
> >
> > Does anyone have a pointer for these sources? I couldn't find
> > anything on the above URL.
> >
> > Thanks,
> >
> > --
> > Michael D. Hirsch Work: (404) 727-7940
> > Emory University, Atlanta, GA 30322 FAX: (404) 727-5611
> > email: [EMAIL PROTECTED] http://www.mathcs.emory.edu/~hirsch/
> >
> > Public key for encrypted mail available upon request (or finger
> > [EMAIL PROTECTED]).
--
Michael D. Hirsch Work: (404) 727-7940
Emory University, Atlanta, GA 30322 FAX: (404) 727-5611
email: [EMAIL PROTECTED] http://www.mathcs.emory.edu/~hirsch/
Public key for encrypted mail available upon request (or finger
[EMAIL PROTECTED]).
------------------------------
From: "Aaron Thompson" <[EMAIL PROTECTED]>
Subject: Re: Need a.out compiler
Date: Mon, 28 Jun 1999 17:30:41 -0500
ie...make a cross compiler. i already treid that. it works and seems to
run, but it fails when trying to link to __main in libgcc.a
i also tried making the embedded i386-aout compiler in gcc 2.8.1, but the
linker that produces can't like a damned thing together without blowing up.
the very old distribution idea is the best yet. i will try. any help is
appreciated.
Konrad Mieredorff wrote in message <[EMAIL PROTECTED]>...
>Aaron Thompson wrote:
>>
>> exactly. i need the libs.
>>
>
>Maybe this question is naive but why don't you compile the libs as
>a.out?
------------------------------
Date: Mon, 28 Jun 1999 18:59:48 +0100
From: Adam Brinley Codd <[EMAIL PROTECTED]>
Subject: Re: File Allocation Tables
> > > You'll find some format info in the Documentation directory of the
> > > kernel source. The guy who wrote the FAT filesystem support has
> > > documented it some.
> >
> > Is this available on a web site somewhere, because I can't find the
> > directory on my CD?
>
> http://www.kernelnotes.org/
>
> Half way down the page, under the _Kernel_Development_Information_
> section is a subsection titled _Source_Browsers_.
Thanks,
You've been a great help.
Adam.
------------------------------
From: [EMAIL PROTECTED] (John McKown)
Subject: Re: help me please, URGENT
Date: 28 Jun 1999 23:31:58 GMT
On Mon, 28 Jun 1999 10:37:27 +0200, Thierry BUCCO
<[EMAIL PROTECTED]> wrote:
>setbuf(stdout_file, NULL);
>
>In fact i want to retrieve all stdout and stderr information, and put then
>into a file. The problem is : the file is created, but there's nothing into.
>I must stop my program to see information (empty buffer ?)
>
>How can i resolve my problem ?
First, do you realize that your second freopen, for stderr, basically
destroys the contents of the variable stdout_file. Or is that a mistype?
Anyway, what I'd try, if you haven't already, is to put an fflush() call after
each fprintf() (or whatever you're using). This should force the buffers
to be flushed to disk. I've done something similiar to write to the
/dev/tty so that prompts appear before I ask for data.
I hope this is of some help to you,
John
------------------------------
From: Jim Robertson <[EMAIL PROTECTED]>
Subject: Re: Can Linux Boot and Run without a BIOS?
Date: Mon, 28 Jun 1999 23:39:54 GMT
Not sure what 'chaos' is, but I understand that the Pentium comes up in
'System Management' mode. You'd have to: 1) get the kernel image into
RAM some way, as everyone has said; 2) switch the CPU into 'Real
[Supervisor?]' mode and 3) jump to the start point. As I understand it,
system management mode gives the CPU some extra I/O ports or something,
so that the BIOS can configure peripherals and such. Sorry, sorta vague
on the details. For a typical desktop, step 2 may not be needed at all.
I have a Pn'P modem card, and Linux sets that up just fine without BIOS
help.
However, I'm pretty sure that once Linux is running, it does not depend
on the BIOS at all. Of course, the root file system must reside on a
device whose driver is not in a module, but compiled into the kernel.
[EMAIL PROTECTED] wrote:
>
> Can Linux boot from chaos and run, without a BIOS?
>
> regards
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.
-- JRob
If I owned Hell and Texas I'd rent out Texas and move to Hell.
------------------------------
From: Michael Hirsch <[EMAIL PROTECTED]>
Subject: Re: PTHREADS kernel/user level threading?
Date: 28 Jun 1999 19:54:56 -0400
Dave Erdmann <[EMAIL PROTECTED]> writes:
> I am wondering if the pthreads implementation on
> Linux does any kernel level threading, or both
> kernel and user level threading.
>
> For instance if I have a dual CPU system can my server
> take advantage of both CPUs having two concurrent
> threads in the same process running on both CPUs
> at once?
That is exactly what it does. As far as the kernel is concerned, each
thread is a separate process.
--
Michael D. Hirsch Work: (404) 727-7940
Emory University, Atlanta, GA 30322 FAX: (404) 727-5611
email: [EMAIL PROTECTED] http://www.mathcs.emory.edu/~hirsch/
Public key for encrypted mail available upon request (or finger
[EMAIL PROTECTED]).
------------------------------
Crossposted-To: comp.arch,comp.object,comp.os.inferno,comp.os.linux.development.apps
From: [EMAIL PROTECTED] (Jennifer Radtke)
Subject: Call for Papers for OSDI 2000-USENIX Operating Systems Symposium
Date: Mon, 28 Jun 1999 23:33:43 GMT
4TH SYMPOSIUM ON OPERATING SYSTEMS DESIGN & IMPLEMENTATION OSDI 2000
October 23-25, 2000, San Diego, California, USA
Sponsored by the USENIX Association
Co-sponsored by IEEE TCOS and ACM SIGOPS.
=============================================================
CALL FOR PAPERS NOW AVAILABLE
Please review at http://www.usenix.org/events/osdi2000
Paper submissions due Tuesday, April 25, 2000.
=============================================================
We would like to invite you to participate. OSDI emphasizes both innovative
research and quantified experience in the systems area. The Symposium
takes a broad view of what the systems area encompasses and seeks
contributions from all fields of systems practice, including: operating
systems, networking, distributed systems, parallel systems, mobile systems,
embedded systems, and the influence of hardware developments on systems and
vice-versa. We particularly encourage contributions containing highly
original ideas.
The goal of the Symposium on Operating Systems Design and
Implementation is to present innovative, exciting work in the
systems area. OSDI brings together professionals from academic and
industrial backgrounds and has become a premiere forum for discussing the
design, implementation, and implications of systems software.
The symposium will provide a single-track of refereed paper presentations
and a keynote address. Work-in-Progress presentations are planned, and
informal Birds-of-a-Feather sessions may be organized by attendees.
We hope to see you there!
Mike Jones and Frans Kaashoek
OSDI Co-Chairs
=============================================================
USENIX, the Advanced Computing Systems Association, is the international,
not-for-profit society made up of scientists, engineers, and system
administrators working on the cutting edge of systems and software. For 25
years USENIX conferences and workshops have emphasized quality exchange of
technical ideas unfettered by stodginess or commercialism.
------------------------------
From: David Wragg <[EMAIL PROTECTED]>
Subject: Re: PTHREADS kernel/user level threading?
Date: 28 Jun 1999 18:17:32 +0000
Dave Erdmann <[EMAIL PROTECTED]> writes:
> Hi I thinking of writing a threaded server
> on the latest Red Hat 6.0 Linux distribution
> using Pthreads.
>
> I am wondering if the pthreads implementation on
> Linux does any kernel level threading, or both
> kernel and user level threading.
Kernel level threading.
> For instance if I have a dual CPU system can my server
> take advantage of both CPUs having two concurrent
> threads in the same process running on both CPUs
> at once?
Yes.
> Does anyone know if this is supported or is there just
> user level threading where the process is shunted onto
> one CPU and does its threading on its own, and can't use
> the multiple CPU's?
The main thing to watch out for is that LinuxThreads doesn't implement
the Pthreads signal behaviour. Otherwise you should be fine. RH6 even
has gdb with thread support.
David Wragg
------------------------------
From: [EMAIL PROTECTED] (Philipp Thomas)
Subject: Re: Need help porting DOS app that uses parallel port (Part II)
Date: Mon, 28 Jun 1999 23:37:58 GMT
On 24 Jun 1999 18:18:23 GMT, [EMAIL PROTECTED] (Chris A. Henesy)
wrote:
>communications protocol with the card is provided. I just have to add the
>code to make it a kernel module, and to have it talk through the
>appropriate kernel interfaces to the parallel port and not directly
>to the hardware. How close am I here? Anyone have any suggestions as to
>which kernel modules I should use as an example? What kernel code I
>should look at to start with?
As it's attached to the parallel port, you'd best use the lowlevel
parport support in Linux 2.2.X and above. I'd suggest looking at ppa.c
(Iomega Zip) or the paride drivers.
I'd also suggest asking the people on the Linux parport mailing list
([EMAIL PROTECTED]) as there you'll find the specialists :)
Philipp
--
Close the windows! The penguin is freezing.
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Reply-To: [EMAIL PROTECTED]
Date: Tue, 29 Jun 1999 01:31:56 GMT
On Mon, 28 Jun 1999 19:43:39 GMT, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>Look at the above, and what I quoted from Nathan Myers:
>
> "[...]Take for example Egcs. C and C++, same code generator,
> same optimizer."
>
>My point was that C++ output is still bigger than C, _for the exact same
>source code_, using the same code generator and optimizer.
...Which basically goes to say that the C++ implementation is not as
*mature* as the C implementation.
They may both share the same peephole optimizer; they may both share the
same RTL code generators.
But they manifestly *do not* share the same parse tree generator.
(That's kind of the point of them being separate compiler front ends.)
It is quite evident that the front ends generate code differently, and
this nicely explains the differences in behaviour.
It is manifestly true that G++ FE != GCC FE, and it is pretty evident
that the GCC FE is *vastly* more mature. Which strikes me as obvious; I
was using GCC (ANSI C) ten years ago, and considered it quite stable,
when G++ was not even worth considering.
All of this being said, it is possible for the code generator for C++
(particularly for EGCS) to persistently underperform the C code
generator, due to the following two factors:
a) They are separate.
b) C++ is a more complex language, thereby making it more difficult to
write a generator producing code that is both correct and efficient.
Don't misread that as a claim that the complexity makes it inherently
*impossible* to make a C++ implementation more efficient; it merely
indicates that it is a difficult task.
--
"I think it would be great if MS would make VB the favoured language
for Palm PC's. Then they'd have a shaky, bloated, slow OS running the
shaky, bloated, slow macro-apps." -- <[EMAIL PROTECTED]>
[EMAIL PROTECTED] <http://www.ntlug.org/~cbbrowne/langc.html>
------------------------------
From: Konrad Mieredorff <[EMAIL PROTECTED]>
Subject: Re: File max size
Date: Tue, 29 Jun 1999 03:03:12 +0200
Patrick Letovsky wrote:
>
> Hi,
>
> What about i386 platform ?
> NTFS can create file bigger than 2Gb !
> It's an ext2 limitation on i386 platform, is there any patch out there
> to create file bigger ?
This is an FAQ (www.dejanews.com)
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: comp.os.linux.misc,comp.os.linux.setup
Subject: Re: Filesize larger than 2 GB on Intel machines an Linux 2.0.36
Reply-To: [EMAIL PROTECTED]
Date: Tue, 29 Jun 1999 01:46:59 GMT
On Mon, 28 Jun 1999 16:19:14 -0700, Patrick Letovsky
<[EMAIL PROTECTED]> wrote:
>"Axel H�lzer" wrote:
>> is there any solution to work with files larger than 2 GB on
>> Intel-processor based machines? I am running RedHat Linux 5.2 with
>> kernel 2.0.36. I heard about patch for kernelversions 2.2.x.
>>
>I heard the same thing, but I can't find any information on this patch
>to override the limitation.
Such a change, in order to *actually prove useful,* needs to be
reflected not only within the kernel, but also in LIBC.
After all, you probably don't want to have to create a custom version of
TAR, a custom version of cp, and a custom version of grep in order to
work with those files, right?
--
Rules of the Evil Warlord #77. "I will design fortress hallways with
no alcoves or protruding structural supports which intruders could use
for cover in a firefight."
[EMAIL PROTECTED] <http://www.ntlug.org/~cbbrowne/lsf.html>
------------------------------
From: [EMAIL PROTECTED] (Nathan Myers)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 28 Jun 1999 18:43:11 -0700
In article <JDQd3.872$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>Nathan Myers <[EMAIL PROTECTED]> wrote:
>: Without proof, [an assertions that C compilers produce better code]
>: is just more FUD.
>
>You cannot find a random C program and compile it yourself with g++?
>long boing (long foo)
>{ if (foo > 1) return (foo * boing(foo - 1)); return 1; }
Just as I thought. Rather than presenting a real program, and
examining the instructions generated and the real execution
speed, he gives us a toy program and compares a line count
of the runtime apparatus.
If the claim had any merit we would have seen real evidence instead
of hastily-contrived FUD.
--
Nathan Myers
[EMAIL PROTECTED] http://www.cantrip.org/
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: comp.os.linux.misc,comp.os.linux.setup
Subject: Re: Filesize larger than 2 GB on Intel machines an Linux 2.0.36
Reply-To: [EMAIL PROTECTED]
Date: Tue, 29 Jun 1999 01:32:01 GMT
On Mon, 28 Jun 1999 16:19:14 -0700, Patrick Letovsky
<[EMAIL PROTECTED]> wrote:
>"Axel H�lzer" wrote:
>> is there any solution to work with files larger than 2 GB on
>> Intel-processor based machines? I am running RedHat Linux 5.2 with
>> kernel 2.0.36. I heard about patch for kernelversions 2.2.x.
>>
>I heard the same thing, but I can't find any information on this patch
>to override the limitation.
Such a change, in order to *actually prove useful,* needs to be
reflected not only within the kernel, but also in LIBC.
After all, you probably don't want to have to create a custom version of
TAR, a custom version of cp, and a custom version of grep in order to
work with those files, right?
--
Rules of the Evil Warlord #77. "I will design fortress hallways with
no alcoves or protruding structural supports which intruders could use
for cover in a firefight."
[EMAIL PROTECTED] <http://www.ntlug.org/~cbbrowne/lsf.html>
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Proposal For New Windowing software
Reply-To: [EMAIL PROTECTED]
Date: Tue, 29 Jun 1999 01:31:45 GMT
On Mon, 28 Jun 1999 09:40:08 -0400, Matthew Carl Schumaker
<[EMAIL PROTECTED]> wrote:
>During the past couple weeks I've seen many people express their opinions
>on both Xwindows and C++. The project that I'm proposing is one that I
>not only want seen done but is also one that I want to participate in.
>
>The proposal is for a new Windowing System that is based on the premise of
>a 3D UI. I know other people are interested in this sort of program as
>well as a couple private ventures, but to the best of my knowledge there
>is no Open Source project of this type.
Have you looked at Berlin? It is seeking to build a GUI system using
CORBA, GGI, and OpenGL/Mesa.
It *looks* like they're primarily working on the 2D aspects of it;
presumably they figure it makes sense to have that somewhat working
first.
--
"What you end up with, after running an operating system concept
through these many marketing coffee filters, is something not unlike
plain hot water." -- Matt Welsh
[EMAIL PROTECTED] <http://www.hex.net/~cbbrowne/xbloat.html>
------------------------------
From: Konrad Mieredorff <[EMAIL PROTECTED]>
Subject: Re: Ultimate OS
Date: Tue, 29 Jun 1999 02:38:54 +0200
Tomas Ogren wrote:
>
> At 23 Jun, Konrad Mieredorff wrote:
>
> > RaiX wrote:
> >>
> >> Linux with netscape as GUI.
> >> That's it..
> >
> > Should I laugh or cry?
>
> Both.. I guess..
Your answer made me laugh or at least smile (not about you -- I just
imagined who I'd look when laughed and cried at the same time)
------------------------------
From: [EMAIL PROTECTED] (Sudip Sarbajna)
Subject: Re: tcp port no.s vs. processes
Date: 29 Jun 1999 02:02:56 GMT
Thanks - I was wandering why am I missing it from my system. Now it is clear
that I need to install it.
Pls. tell me where do I get it from or any pointer.
Thanks
Sudip
------------------------------
From: [EMAIL PROTECTED] (Nathan Myers)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking,comp.lang.c++
Subject: Re: Why not C++
Date: 28 Jun 1999 18:55:40 -0700
Greg Comeau <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Nathan Myers) writes:
>>John E. Davis <[EMAIL PROTECTED]> wrote:
>>> In my opinion, the only thing that C++ has over C is
>>>better support for data encapsulation via classes and, possibly,
>>>exception handling. Other features such as operator overloading I can
>>>do without because of the potential for abuse.
>>
>>Classes are not a very powerful feature; you can emulate them pretty
>>well in C. Exceptions are quite powerful, though of limited use.
>>Far more powerful than either are templates.
>
>However, I think it's an overstatement
>to say that classes are not a very powerful feature and that they can
>be emulated well in C. I'm thinking of inheritance and virtuals
>as class features. I don't think they emulate well in C at all.
>But even w/o them, and that "C techniques" are rather mechanical
>at just the raw class level on some things, I still don't think they
>emulate well in C. Why do you want to have to do the mechanics?
Of course I'd rather write inheritance in C++, but the architecture
of GNOME and much of the Linux kernel are predominantly emulations of
virtual functions in C. While a clear notational win, the lack doesn't
seem to slow anybody down. Still, most times I see a function pointer
it turns out to be virtual function dying to be recoded recognizably
in C++.
Alex Stepanov has said that he would happily do without member functions,
and regrets those parts of the STL spec that require them. I suspect
Alex doesn't use function pointers much.
--
Nathan Myers
[EMAIL PROTECTED] http://www.cantrip.org/
------------------------------
** 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: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
