Herbert Kleebauer wrote:
> Frank Kotler wrote:
>> Herbert Kleebauer wrote:
>
>
>>> to C so you can do graphics in a C program without any graphics
>>> library.
>> Before you waste your time, explain to me how this would be "better".
>
> Better than what? C better than assembler? Or no library better than
> a graphics library.
C better than assembly. Library vs no library is a separate issue.
(though relevant to the original topic, perhaps)
> 10 years ago I wrote a jpeg viewer for encrypted multi-jpeg
> files.
Cool! (judging just from the description of what it does)
> Look at the source code and you will know why for this program
> C is better than assembler
Probably not a good idea to assume what I will "know"... or not.
> ( ftp://137.193.64.130/jpeg/pfp.zip ).
Ahhh, okay... "access denied, too many anonymous users" a lot. Then, you
need a "pub/" in there...
Unzips into current directory.
UPPERCASE FILENAMES.
....already, I'm annoyed, before I even get to the relevant part. I *try*
not to let this cloud my judgement...
> All OS specific code is in a separate file (currently for DOS and
> for Windows)
Okay, I see "win.c"... "WIN.C", mean. I guess "CRYP.C" is the dos one(?)
- seems to be where "main" lives, anyway... (I can't even find the
goddam "_start" label or other entrypoint in C! Oh, that's right, it's
"hidden"...) In the MAKEPFP/SOURCE directory I see .asm.... I mean
".MAC" files...
Then I see stuff like (random snippet):
if (encrypt)
{p=head; while (*p) putc(*p++,out);
for (i=0; i<8; i++) dat[i]=i;
crypt(dat,key2i); modify(key2,key2i);
for (j=0;j<8;j++) putc(dat[j],out);
dat[0]=dat[1]=dat[2]=dat[3]=0;
dat[4]=(size>>24);
dat[5]=(size>>16);
dat[6]=(size>> 8);
dat[7]=(size );
crypt(dat,key2i); modify(key2,key2i);
for (j=0;j<8;j++) putc(dat[j],out);
size=(size+7)&0xfffffff8;
}
while ((i=getc(in))!=EOF)
{dat[0]=i;
for (j=1;j<8;j++) dat[j]=getc(in);
if (decrypt) crypt(dat,key1); modify(key1,key1i);
if (encrypt) crypt(dat,key2i); modify(key2,key2i);
for (j=0;j<8;j++) put_byte(dat[j]);
}
ende(0,0);
}
What is it I'm supposed to "know" from looking at this, Herbert? I can
puzzle out what it does, I guess (I *can* read C, to an extent - I just
don't "like" to). For the sake of argument, suppose we've got an asm
version of this exact code. (tried gcc -S but gcc isn't having any)
Granted, it (too!) will be pretty incomprehensible at first glance.
Longer, almost certainly ("taller"). If we allow the same number of
comments as you use, we'd want really "meaningful" names for variables,
functions, labels... "modify" might want to explain to us in what way
it's being modified, for example. I like "short" executables, but I
don't extend that to source code. You (and Rosario) like "terse" labels
(letter 'a', numeral '1' looks an awful lot like "al", 'rio!). I'm
coming to the opinion that "overly verbose" is a lot "better" than
overly "terse".
I'd argue that we'd see what we're asking the CPU to do better in the
assembly version. There may be redundant, detoured, or otherwise
"useless" code that isn't obvious in the C version - depends on the
compiler, *and* what it's being asked to do (you're good at this latter
part). Perhaps we see "what's this doing for me" better in C - depends a
lot on how the asm is written/commented, IMO.
Are you referring to the fact that you've got multiple object files?
Most assemblers will do that. In view of our discussions of
"bike"/"motorbike" and "assembler"/"macro assembler", I should make
clear that I'm talking about a "linkable object file emitting macro
assembler" (not necessarily Nasm specifically, but "like that")
With a suitably powerful "macro assembler", we could make the "asm" code
*look* a lot like the C code. Would that be "better" than "plain asm",
in your opinion?
What am I supposed to "see" that I'm missing?
> and it's still on the to-do list to make one for Linux.
I wouldn't discourage you from doing that! I might not "participate",
even "follow along" - jpegs are pretty far "down" (as in "later") on my
TODO list - but I think it's an excellent idea!
> I don't like it to depend on the existence of libraries if
> this isn't absolutely necessary.
It's *never* absolutely necessary! Hellishly impractical to get along
without 'em sometimes (and perhaps pointless). But it's "possible"... if
you want to... badly enough...
> I know that I need a X server
Yeah... there's the frame buffer device, svgalib... Richard Cooper, aka
PJ, showed us "softer", which does graphics by manipulating ****ts. Vga
only, but one *could* provide separate routines for each card sup****ted.
"No one in his right mind" would do it that way. But that's
discrimination! :)
> (but that should be available on nearly any Linux with a GUI) but
> anything else can directly be done in the user program.
Agreed.
>> Does the phrase "sick C religion" ring a bell? :)
Perhaps I should explain the "in group" joke. Old-timers will recall
that before clax, there was comp.lang.asm... plagued with a guy who used
that expression. I remembered it as "you only see what your sick C
religion allows you to see", but Phil reminded me that the actual quote
was "you only what your sick C religion allows you to see" -
consistently, apparently "cut and past". Some folks who should have
known better continued to reply to him... "lest the newbies be misled".
And that's why clax is moderated...
I withdraw "sick". I still think that the belief that C is "inherently
superior" to asm (or any other language - there are more than two
combatants - and as Chuck points out, the "sickness" is in thinking of
them as "combatants") might count as a "religion".
> No, I only know a "sick assembly religion". A C programmer
> will go down to assembly if appropriate,
Uhhh, not all C programmers *know* assembly. A "good" programmer might
object to being called a "C programmer" - he'd know several languages,
and use the "most appropriate" - according to whatever criteria he damn
well pleases (that's the nice part of being the programmer!). A
"professional" programmer might have to use what the boss wants...
unless he *is* the boss...
> some assembly
> programmer on the other side seem to think, a HLL is
> completely useless.
Nothing's *completely* useless. We always need something to wipe our ass
with, if nothing else. *I* don't argue that C is useless. (almost "a
necessity" if we want cross-architecture ****tability, and it makes
cross-platform ****tability more convenient) I *do* argue with the notion
that C is "inherently superior" to assembly.
Best,
Frank
|
