see below, plz.
Dick
----- Original Message -----
From: "Sean 'Captain Napalm' Conner" <spc(a)conman.org
To: <classiccmp(a)classiccmp.org
Sent: Monday, April 22, 2002 7:50 PM
Subject: Re: Micro$oft Biz'droid Lusers (was: OT email response format)
It was thus said that the Great Richard Erlacher once
stated:
From: "Sean 'Captain Napalm' Conner" <spc(a)conman.org>
But to
catagorize all of them as ``development-related tools'' is a
disingenious thing to say.
disingenuous, is what you mean, isn't it?
Yes it is. That's what I get for not taking the time to look up the
proper spelling.
Well, I had to pick on you about something.
Why would anyone outside the UNIX/APPLE world
care about postscript files?
That was once a popular format, but things change.
PDF seems to be a very popular format these days and that's based upon
PostScript. You can still get printers that support PostScript but hey, if
PostScript isn't your bag, then there are programs to convert the output
from TeX/LaTeX into your favorite printer format (as long as documentation
exists for it that is).
Which is why PS is of no particular use to most of us.
> > > Even in hardware development, the
> > > software is a burden. It's a burden on the cost of other goods and
> > > services.
>
> > What does this even mean?
> It simply means that if you have to
generate software that's not what your
> main product line is, it's overhead. If you're a school system and you
have
> to write your own code to manipulate the test
score records demanded by
the
> legislature, that's an overhead item, since
it doesn't contribute to the
> process of educating the kids. If you're a hardware developer and you
have to
> write a compiler for the CPU you've designed
into the gate array you're
going
to ship,
that's overhead that adds to the systemic burden, yet doesn't
increase the price you can get for your product. Unless you're selling
software, generating software is a cost, not a benefit.
You can either manage the test scores on paper, or on a computer. While
it may seem to be cheaper to do it by hand, there are benefits to going the
computer route, expense or not. Storage space is one consideration. Speed
of processing is another. Unless you really advocate going back to paper
records for everything?
Whichever way you do it, it's overhead, since it doesn't contribute to the
bottom line.
You're going to have to write an assembler too, else you end up with a
useless piece of silicon. Face it---without software, programmable hardware
isn't going to do much other than be an expensive paperweight. I would
contend that without software, then who in their right mind is going to use
your hardware?
Well, you CAN design in a core for which you've already got an assembler.
And it's not like you, as the hypothetical hardware chip maker, have to
start from scratch and generate a compiler from the ground up. GCC can be
configured to compile code for your chip, and while such a task isn't
trivial, it's easier than having to generate a compiler from the ground up
(and yes, documentation exists for this although how good it is, I'm not
sure). And with GCC, you get not only a C compiler, but C++, Fortran and
Ada as well. And if GCC is not to your liking, there is also LCC, which was
designed from the ground up to be an easily retargettable C compiler (and
that comes with extensive documentation).
That doesn't take the task out of the overhead column, though.
-spc (Guess its back to using the abacus to keep business records ... )
The abacus is in the facilities column, which is overhead, and using it is
overhead.