Peter Flass <peter_flass@yahoo.com> writes:
><greenaum@gmail.com> wrote:
>> On Sat, 24 Apr 2021 15:45:16 -0700, Peter Flass <peter_flass@yahoo.com> sprachen:
>>
>>> This used to be true. In early days C added only a few bytes of overhead to
>>> your object program, and generated straightforward code. Now it’s just
>>> another high-level language, with all the plusses and minusses of that, but
>>> it comes with a lot of cruft. Probably the cross-compilers for embedded
>>> systems are still relatively clean.
>>
>> I think a lot of that might be to do with the little dance programs have
>> to do with the operating system, stick corks in the
>> necessary holes. That would explain why embedded systems still stay
>> clean. That, and necessity for 8K flash and 256 bytes RAM or
>> whatever you've got. The C you're complaining about wouldn't be the other
>> kind of "cross" would it? ++ ? Sign of the double cross!
>>
>
>Gcc pulls in a lot of stuff, even for a minimal program.

Can you elaborate? How many programs have you written using
GCC?

It's been my experience that you can do anything you want with
GCC, including creating minimal programs that have a microscopic
memory footprint.

It really depends on what you want to do.

> In olden days you
>could write a C program for DOS to read data from the console and display

In the old days (pre 1982), there wasn't a C compiler for MSDOS.

In any case, you can still write such a program in C, using GCC or ICC
or most other C compilers using just your own code. If you're masochistic
enough to want to do so. You don't _need_ the libraries, but you'd
be crazy not to use them in these modern times.

> It's been my experience that you can do anything you want with
> GCC, including creating minimal programs that have a microscopic
> memory footprint.

> It really depends on what you want to do.

Seems like a good place to drop a link to this:

https://www.muppetlabs.com/~breadbox/software/tiny/teensy.html

for those who might want to try the concept.

De

On Tue, 27 Apr 2021 14:04:54 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:

> In the old days (pre 1982), there wasn't a C compiler for MSDOS.

At Inelegant^WIntelligent Software I used a C compiler on one of
CP/M-86 or MSDOS (the machine ran both - I think the compiler was for
CP/M-86 BICBW) it was a stripped down C (no bit field in structs for a
start) but it worked. I used it to build a remote debugging/development tool
for games consoles (dummy cartridge with RAM, bootstrap ROM and RS232 to
computer - we got pretty slick at knocking them up for various consoles).
The assembler and disassembler were processor agnostic with tables defining
the ISA). Meanwhile Nick Toop was upstairs working on the Elan Enterprise
design.

--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/

Dennis Boone <drb@ihatespam.msu.edu> wrote:
> > It's been my experience that you can do anything you want with
> > GCC, including creating minimal programs that have a microscopic
> > memory footprint.
>
> > It really depends on what you want to do.
>
> Seems like a good place to drop a link to this:
>
> https://www.muppetlabs.com/~breadbox/software/tiny/teensy.html
>
> for those who might want to try the concept.
>
> De
>

Interesting, but this is saving bytes on disk, not all of which usually
make it into memory anyway.

--
Pete

> Interesting, but this is saving bytes on disk, not all of which usually
> make it into memory anyway.

I think you've missed the point. Before he gets off into the weeds of
re-using parts of the ELF header etc to save bytes, he demonstrates
what's needed to build executables with the gcc toolchain that don't
drag in the standard crt0 and library bits.

De

On Tue, 27 Apr 2021 15:41:33 -0500
drb@ihatespam.msu.edu (Dennis Boone) wrote:

> > Interesting, but this is saving bytes on disk, not all of which usually
> > make it into memory anyway.
>
> I think you've missed the point. Before he gets off into the weeds of
> re-using parts of the ELF header etc to save bytes, he demonstrates
> what's needed to build executables with the gcc toolchain that don't
> drag in the standard crt0 and library bits.
>
> De

Pah DOS (.com files, anyhow) don't need no steenkin headers.

--
Bah, and indeed Humbug.

Dennis Boone <drb@ihatespam.msu.edu> wrote:
> > Interesting, but this is saving bytes on disk, not all of which usually
> > make it into memory anyway.
>
> I think you've missed the point. Before he gets off into the weeds of
> re-using parts of the ELF header etc to save bytes, he demonstrates
> what's needed to build executables with the gcc toolchain that don't
> drag in the standard crt0 and library bits.
>
> De
>

Thanks, I skimmed it, but saved a link to review later. When I’m talking
about C on a PC, my first compiler was “Aztec C”, which was pretty basic
with no overhead. Then I used Borland Turbo-C. I think I used VAX C at one
point, and only a bit of Gcc for Linux.

--
Pete

On 28/04/2021 23:40, Peter Flass wrote:
> Dennis Boone <drb@ihatespam.msu.edu> wrote:
>> > Interesting, but this is saving bytes on disk, not all of which usually
>> > make it into memory anyway.
>>
>> I think you've missed the point. Before he gets off into the weeds of
>> re-using parts of the ELF header etc to save bytes, he demonstrates
>> what's needed to build executables with the gcc toolchain that don't
>> drag in the standard crt0 and library bits.
>>
>> De
>>
>
> Thanks, I skimmed it, but saved a link to review later. When I’m talking
> about C on a PC, my first compiler was “Aztec C”, which was pretty basic
> with no overhead. Then I used Borland Turbo-C. I think I used VAX C at one
> point, and only a bit of Gcc for Linux.
>

I had Zorland C for the 16 bit DOS world.

I think that they were trying to parasitise off the Borland name!

On 2021-04-28, Peter Flass <peter_flass@yahoo.com> wrote:
> Dennis Boone <drb@ihatespam.msu.edu> wrote:
>> > Interesting, but this is saving bytes on disk, not all of which usually
>> > make it into memory anyway.
>>
>> I think you've missed the point. Before he gets off into the weeds of
>> re-using parts of the ELF header etc to save bytes, he demonstrates
>> what's needed to build executables with the gcc toolchain that don't
>> drag in the standard crt0 and library bits.
>>
>> De
>>
>
> Thanks, I skimmed it, but saved a link to review later. When I’m talking
> about C on a PC, my first compiler was “Aztec C”, which was pretty basic
> with no overhead. Then I used Borland Turbo-C. I think I used VAX C at one
> point, and only a bit of Gcc for Linux.
>

I remember Lattice C which also carried my First virus, then there was
Dice C, I think, which was, I think, slightly abberant, but really
worked. After that, it was interpeters all the way.

On Wed, 28 Apr 2021 15:40:35 -0700
Peter Flass <peter_flass@yahoo.com> wrote:

> and only a bit of Gcc for Linux

Oh dear, gcc is somewhat older than Linux (it came out in 1987),
for some years it was popular in many unix houses because it ran on all the
myriad variants of unix you could find and made porting applications a
*lot* easier when at least the compiler was consistent.

I had my copies of the GNU and X11 tapes about the time Linux was
starting to turn into an OS (I got X11R5 when it was very new). They weren't
easy to get and the X11 tape was even less easy to compile and get running.

--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/

On Thu, 29 Apr 2021 11:36:06 +0100, gareth evans <headstone255@yahoo.com> wrote:
> On 28/04/2021 23:40, Peter Flass wrote:
>> Dennis Boone <drb@ihatespam.msu.edu> wrote:
>>> > Interesting, but this is saving bytes on disk, not all of which usually
>>> > make it into memory anyway.
>>>
>>> I think you've missed the point. Before he gets off into the weeds of
>>> re-using parts of the ELF header etc to save bytes, he demonstrates
>>> what's needed to build executables with the gcc toolchain that don't
>>> drag in the standard crt0 and library bits.
>>>
>>> De
>>>
>>
>> Thanks, I skimmed it, but saved a link to review later. When I’m talking
>> about C on a PC, my first compiler was “Aztec C”, which was pretty basic
>> with no overhead. Then I used Borland Turbo-C. I think I used VAX C at one
>> point, and only a bit of Gcc for Linux.
>>
>
> I had Zorland C for the 16 bit DOS world.
>
> I think that they were trying to parasitise off the Borland name!

Borland started with Turbo C in 1987. Zortech released Zorland C about
a year before that. At the time of release Borland were really only
known for Turbo Pascal and Sidekick so it seems a strange hill to make
a stand on.

Zortech was a British company.

I started with C on 4.2BSD running on a Vax at college but then when I
got a job it was Lattice-C on Wndows. At home I had a year or two with
Turbo C before I moved to a Linux machine.

--
Andy Leighton => andyl@azaal.plus.com
"We demand rigidly defined areas of doubt and uncertainty!"
- Douglas Adams

Ahem A Rivet's Shot <steveo@eircom.net> writes:
>On Wed, 28 Apr 2021 15:40:35 -0700
>Peter Flass <peter_flass@yahoo.com> wrote:
>
>> and only a bit of Gcc for Linux
>
> Oh dear, gcc is somewhat older than Linux (it came out in 1987),
>for some years it was popular in many unix houses because it ran on all the
>myriad variants of unix you could find and made porting applications a
>*lot* easier when at least the compiler was consistent.
>
> I had my copies of the GNU and X11 tapes about the time Linux was
>starting to turn into an OS (I got X11R5 when it was very new). They weren't
>easy to get and the X11 tape was even less easy to compile and get running.

I've still got the X11R3 QIC tape and a 9-track GCC tape that we ordered
from the FSF circa 1989/1990.

GCC, at the time, was inferior to the native SVR4 SGS C compiler, although
it was better than the PCC compiler we were using with the Motorola 88100.

On Thu, 29 Apr 2021 16:52:09 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:

> GCC, at the time, was inferior to the native SVR4 SGS C compiler, although
> it was better than the PCC compiler we were using with the Motorola 88100.

From our point of view (more than one our) the quality
considerations were overridden by being able to have the same compiler for
all the ports.

--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/

Ahem A Rivet's Shot <steveo@eircom.net> wrote:
> On Wed, 28 Apr 2021 15:40:35 -0700
> Peter Flass <peter_flass@yahoo.com> wrote:
>
>> and only a bit of Gcc for Linux
>
> Oh dear, gcc is somewhat older than Linux (it came out in 1987),
> for some years it was popular in many unix houses because it ran on all the
> myriad variants of unix you could find and made porting applications a
> *lot* easier when at least the compiler was consistent.
>
> I had my copies of the GNU and X11 tapes about the time Linux was
> starting to turn into an OS (I got X11R5 when it was very new). They weren't
> easy to get and the X11 tape was even less easy to compile and get running.
>

I tend to conflate Linux and Unix. People keep wanting to make the
distinction, but there are many unices, often as different from each other
as any one is from Linux.

--
Pete

On Thu, 29 Apr 2021 18:28:56 -0700, Peter Flass
<peter_flass@yahoo.com> wrote:

>Ahem A Rivet's Shot <steveo@eircom.net> wrote:
>> On Wed, 28 Apr 2021 15:40:35 -0700
>> Peter Flass <peter_flass@yahoo.com> wrote:
>>
>>> and only a bit of Gcc for Linux
>>
>> Oh dear, gcc is somewhat older than Linux (it came out in 1987),
>> for some years it was popular in many unix houses because it ran on all the
>> myriad variants of unix you could find and made porting applications a
>> *lot* easier when at least the compiler was consistent.
>>
>> I had my copies of the GNU and X11 tapes about the time Linux was
>> starting to turn into an OS (I got X11R5 when it was very new). They weren't
>> easy to get and the X11 tape was even less easy to compile and get running.
>>
>
>I tend to conflate Linux and Unix. People keep wanting to make the
>distinction, but there are many unices, often as different from each other
>as any one is from Linux.

I work with an IBM mainframe running Z/OS. Z/OS is a certified Unix.
We run Linux in multiple VMs. So we have Linux running on Unix. In
that connection Linux looks more like Unix than Unix does.

The distinction is that Linux was substantially an independent
development and any AT&T code that got into it was done inadvertently.
This is different from the BSDs which started out as AT&T code and
eventually got sanitized to get out from under AT&T licensing.

Unix is still a registered trademark currently owned by The Open
Group. Who owns the source code is anybody's guess. Xinuos
(descended from SCO) seems to think that they do but the courts ruled
that it belongs to Novell whose remains now belong to Micro Focus.

On Fri, 30 Apr 2021 05:03:17 -0400
J. Clarke <jclarke.873638@gmail.com> wrote:

> The distinction is that Linux was substantially an independent
> development and any AT&T code that got into it was done inadvertently.

Linux the desktop and server OS family was essentially two
independent developments combined. The FSF sponsored GNU collection of unix
like commands and tools and Linus Torvald's kernel - neither of them have
any code from AT&T except (as you say) inadvertently.

> This is different from the BSDs which started out as AT&T code and
> eventually got sanitized to get out from under AT&T licensing.

Sort of - the last act of the BSD group was to release the sanitised
(and incomplete) sources BSD-4.4-Lite and BSD-4.4-Lite-2. There was
remarkably little removed by the settlement which either reflects the
extent to which the original academic licensed sources from AT&T had been
changed by then or horse trading over such things as vi, csh, sockets and
the TCP stack which originated with BSD not AT&T.

What we now think of as typically unix started at AT&T (Bell) and
grew cooperatively between AT&T and BSD with a little input from Microsoft
over many years.

--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/