Frank Kotler wrote:
> Herbert Kleebauer wrote:
> > 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
Yes, my Linux 1.1 was again short of handles and needed a reboot
(seems it doesn't like the access method of some actual browser).
> need a "pub/" in there...
I know, I'm getting old.
> Unzips into current directory.
>
> UPPERCASE FILENAMES.
That is a problem with the good old DOS pkzip. I know I should
use the built-in zip of Windows XP, but I still prefer to use
the Norton Commander in a CMD shell instead of the GUI of Windows.
> ...already, I'm annoyed, before I even get to the relevant part. I *try*
> not to let this cloud my judgement...
I'm not sure what's the reason for being annoyed, DOS/Windows
or Linux. Does it really make sense to distinct between upper and
lower case letters in file names? In DOS/Windows I use a batch
file to convert all filenames to lower case. In Linux you can't
do this because you don't know whether some names have to remain
in upper case.
> > 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(?)
No, the source file is "pfp.c". It includes "fft.c" (the coefficients
for the discrete cosinus transformation and "win.c" (the Windows
specific part) or dos.c (the DOS specific part; this file is not
included in the zip) or linux.c (still has to be written).
"crypt.c" is a stand alone (DOS) program to encrypt a pfp file.
The decryption is done on-the-fly in the viewer pfp.exe so no
decrypted pictures are tem****arily stored on the disk when
the pictures are displayed.
> - 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
WinMain() is in "win.c". For the DOS version there is main() in "dos.c".
> "hidden"...) In the MAKEPFP/SOURCE directory I see .asm.... I mean
> ".MAC" files...
No, all source files for the viewer and the encryption program are in
the "source/" directory. "makepfp/" contains a batch file to sup****t
you in generating the pfp picture file. If all jpegs are baseline
encoded, you can do a simple "copy /b *.jpg pictfile.pfp" to make
the pfp file. makepfp.bat on the other side automatically converts
progressive encoded jpegs to baseline encoded jpegs and also inserts
the original file name and date into the pfp file so you later
can extract the original jpg files from the pfp files (this is not
possible if just use the "copy /b *.jpg pictfile.pfp" command).
>
> Then I see stuff like (random snippet):
Bad random generator. Here the "random" snippet which
decodes the different jpeg types. In opposite to assembly
code, you directly "see" how the bgr (blue-green-red) pixel
array is calculated.
switch (typ)
{case 0:
n1=0;
for (i1=0; i1<8; i1++)
{for (i2=0; i2<8; i2++)
{bgr[n3++]=limit[((a[0][n1])>>16)+128+lmt];
bgr[n3++]=limit[((a[0][n1])>>16)+128+lmt];
bgr[n3++]=limit[((a[0][n1])>>16)+128+lmt];
n1++;
}
n3=n3+(HBMP-8)*3;
}
break;
case 1:
for (i=0;i<64;i++) {a[1][i]=a[1][i]>>12; a[2][i]=a[2][i]>>12;}
n1=0;
for (i1=0; i1<8; i1++)
{for (i2=0; i2<8; i2++)
{bgr[n3++]=limit[((a[0][n1]+a[1][n1]*7258)>>16)+128+lmt];
bgr[n3++]=limit[((a[0][n1]-a[1][n1]*1410-a[2][n1]*2925)>>16)+128+lmt];
bgr[n3++]=limit[((a[0][n1]+a[2][n1]*5743)>>16)+128+lmt];
n1++;
}
n3=n3+(HBMP-8)*3;
}
break;
case 2:
for (i=0;i<64;i++) {a[2][i]=a[2][i]>>12; a[3][i]=a[3][i]>>12;}
for (i1=0; i1<8; i1++)
{for (i2=0; i2<16; i2++)
{n2=i1*8+i2/2; n4=i2/8; n1=i1*8+i2%8;
bgr[n3++]=limit[((a[n4][n1]+a[2][n2]*7258)>>16)+128+lmt];
bgr[n3++]=limit[((a[n4][n1]-a[2][n2]*1410-a[3][n2]*2925)>>16)+128+lmt];
bgr[n3++]=limit[((a[n4][n1]+a[3][n2]*5743)>>16)+128+lmt];
}
n3=n3+(HBMP-16)*3;
}
break;
case 3:
> 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.
That's the big difference between C and assembler. When you only
have CPU instructions in your source, then you need some "HL comments"
to understand the program logic. You could use C like statements
as comment in your assembly source to explain the program logic, but
then in most cases it is better to omit the CPU instructions and
let the compiler generate it from the C like comment directly.
> I'd argue that we'd see what we're asking the CPU to do better in the
> assembly version.
In which of the two version do you see better what you are asking
your girl fried to do:
assembly version:
stand up
a1: if you are looking to the north, goto a2
turn left
goto a1
a2: go 5 steps forward
open the door
go 3 steps forward
turn right
open the door
take the object in front of you
close the door
turn right
go 3 steps forward
close the door
go 5 steps forward
sit down
give me the object
C version:
fetch me a beer!
> part). Perhaps we see "what's this doing for me" better in C - depends a
> lot on how the asm is written/commented, IMO.
No, in C you see what it does and in assembler you see how it does it.
> Are you referring to the fact that you've got multiple object files?
I don't like multiple object files. I prefer a single
gcc -o prog prog.c
to generate the program. This isn't practical for big projects,
but for my small projects this is sufficient (if necessary I
split the source and use "include").
> 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?
To make assembly code look like C code would only make sense
if it then looks better. But if it then looks better, the it
would even make more sense to directly use the better looking
C code.
> > 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...
It is "hellishly impractical" if you are just interested in the
resulting executable. I didn't write the program because I needed
a jpeg viewer (there are plenty of them) but because I wanted to
understand the jpeg compression and encryption algorithms. And
then it doesn't make any sense to call a "decode_jpg()" in
a graphics library or "decrypt()" in an encryption library or
anything else in a user library. I want to see the complete
code down to the native OS calls.
>
> > 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! :)
That has nothing to do with "right mind". The only question is:
will it run on the same amount of systems as the X version will
run. If yes, then I surely would prefer this way.
> 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
That has nothing to do with C or assembler but the abstraction level
(C and assembler are just examples for different abstraction levels).
Some time it is sufficient (or even more appropriate) to say: "fetch
me a beer" (and let the servant decide how to do it) and sometime
it is better to give the order at a much lower level. The essential
thing is, to understand when which level is appropriate. And therefore
it is necessary to be familiar with the different levels.
> Uhhh, not all C programmers *know* assembly.
I hope that's not true.
> 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!).
Sure, C is very low level and surely not the appropriate tool
for many tasks. I was told, Visual Basic is a very powerful tool,
but I'm not interested in anything above the C level. But to stop
already at the assembly level is little bit to low (I think).
> I *do* argue with the notion
> that C is "inherently superior" to assembly.
Is an airplane "inherently superior" to a car? Is a car "inherently
superior"
to a bike? For some travels you better use an airplane, for some others a
car
and sometime a bike is more appropriate. But if you compare the numbers
of km an average man travels ever year with a airplane, car or bike then
there could be the conclusion: for most travels the car is "inherently
superior"
to the airplane and bike. The same seems true for C and assembly.
|
