Java/C/Assembler

[Sudsy]

I guess it's a matter of perspective. I've also seen that the differences
are more than a few percent. We did a test one time. The same project -
requirements, interface, database, everything was given to 2 experienced
groups. My group worked in Assembler and the other used C. The Assembler
package was 6 times faster than the C package and the C package had been
optimized. Both groups completed their assignments in the same time frame.
The C package was easier to understand for most people who weren't into
minutae, but problems were easier to find in the Assembler package because
there wasn't much between the source and the executable (no compiler
problems/eccentricities to deal with) Granted, C programmers are a lot
easier to find and the learning curve for Assembler is a LOT longer. As I
said in an earlier post - you need lots of tools in the toolbox so you know
which to use in a situation.

I've started a new thread for this discussion, which doesn't properly
belong in a Java ng I know. It just struck a chord. I found 122 ops in
my handy System/370 Reference Summary (GX20-1850-5). There's another
bunch of FP instructions which I didn't bother to count.
So then I counted the number of man pages in /usr/man/man2, the system
call documentation, on my Linux box and found 238 system calls.
Finally, just to be anal, I used some of the typical *NIX tools on the
output of 'jar tf $JAVA_HOME/jre/lib/rt.jar' and found 1,688 packages
or classes. I limited the search to the third level.
So how is the learning curve for Assembler a "LOT longer"? Seems that
it would be a lot easier to learn a small instruction set than to
become familiar with hundreds of classes and thousands of methods.
Just asking...

 

[Dave Monroe]

I've started a new thread for this discussion, which doesn't properly
belong in a Java ng I know. It just struck a chord. I found 122 ops in
my handy System/370 Reference Summary (GX20-1850-5). There's another
bunch of FP instructions which I didn't bother to count.
So then I counted the number of man pages in /usr/man/man2, the system
call documentation, on my Linux box and found 238 system calls.
Finally, just to be anal, I used some of the typical *NIX tools on the
output of 'jar tf $JAVA_HOME/jre/lib/rt.jar' and found 1,688 packages
or classes. I limited the search to the third level.
So how is the learning curve for Assembler a "LOT longer"? Seems that
it would be a lot easier to learn a small instruction set than to
become familiar with hundreds of classes and thousands of methods.
Just asking...

You might be amazed . . .

There are so many ways to screw yourself. C programmers are only a
little better off. Assembler is like a bad power tool with _no_
safety features.

Count your fingers when you're done.

 

[Chris Smith]

So how is the learning curve for Assembler a "LOT longer"? Seems that
it would be a lot easier to learn a small instruction set than to
become familiar with hundreds of classes and thousands of methods.
Just asking...

The numbers are not equivalent, and so can't be compared directly. The
instruction set for assembly code represents the purely computational
capabilities of the processor/memory combo, plus the possibility of a
few instructions that relate to external device I/O (unless access to
these devices is provided via MMIO, in which case there would not be
special instructions for it).

By constrast, the standard APIs for C and Java largely skip that whole
space of computation, which is generally provided via keywords and
operators, and provides functionality relating to complex sets of
calculations, or to interaction with external devices.

For a fair comparison, Java has 63 effective keywords as of 1.4, and 48
operators by my count (including uses of parentheses for casts, etc.),
for a total of 111 computational elements. That's about equivalent to
your 122 opcodes for System/370 assembly, and far fewer than the typical
processor, as far as I can see.

Valid comparisons for standard API are meaningless, because there are so
many levels of abstraction and functionality that can be provided. For
example, assembly code has the ability to communicate with external
devices, but it probably involves installing IRQ handlers, knowing the
layout of memory-mapped registers for the external device, and learning
a possibly complex communication protocol. Even between C and Java,
Java may have a lot more classes than C has system calls (incidentally,
not the same thing), but your count for C doesn't even include
interacting with a GUI, or doing RSA encryption of arbitrary data, or
even I/O streams and buffering (which are part of C's standard API, but
are definitely not system calls).

The learning curve depends on:

1. The amount you need to know to effectively perform the same tasks.
2. How natural that knowledge is to the person learning.

Clearly, in assembly code, it's necessary to know more than the set of
opcodes in order to perform useful work; and similarly, it's not
necessary to simultaneously memorize the entire core API of Java to do
useful work there. On the other point, for those concepts that do
overlap, Java's natural mathematical notation for computations is far
more natural than assembly mnemonics; and the abstract core API for Java
is certainly more natural than writing IRQ handlers. Same for C.

Hence the claim that C and Java have an easier learning curve.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Robert B.]

I've started a new thread for this discussion, which doesn't properly
belong in a Java ng I know. It just struck a chord. I found 122 ops in
my handy System/370 Reference Summary (GX20-1850-5). There's another
bunch of FP instructions which I didn't bother to count.
So then I counted the number of man pages in /usr/man/man2, the system
call documentation, on my Linux box and found 238 system calls.
Finally, just to be anal, I used some of the typical *NIX tools on the
output of 'jar tf $JAVA_HOME/jre/lib/rt.jar' and found 1,688 packages
or classes. I limited the search to the third level.
So how is the learning curve for Assembler a "LOT longer"? Seems that
it would be a lot easier to learn a small instruction set than to
become familiar with hundreds of classes and thousands of methods.
Just asking...

It's just been my experience that it takes most people a lot longer to get
their hands around Assembler. Learning the language itself isn't that
difficult. I guess the real learning curve comes when you get around to
actually making it do something. Then when you add to that the ability to
do literally anything and there's very little to stop you...

 

[Robert B.]

....clip...

You might be amazed . . .

There are so many ways to screw yourself. C programmers are only a
little better off. Assembler is like a bad power tool with _no_
safety features.

Count your fingers when you're done.

Arghhhh!!!! Brings out the "Tim Taylor" in all of us. MORE POWER!!! I
remember back in my early days... We had a problem with operations getting
things confused when they had to stop a process and do a re-start. We had
morning and evening jcl that had to run with the morning db feeding the
afternoon and afternoon feeding the morning, etc... We came up with a
solution with some code that did some hardware "twiddling". It worked a
charm and both jobs ended up running from one set of JCL. No more problems!
But I got a little antsy about what we were doing and not wanting to be like
the guy who's last were "Hey guys, watch this!", I went to the in-house IBM
guys to verify that what my partner and I had coded was OK... After
explaining what the problem was and what we did, the 2 IBM guys looked at
each other and said "You can't do that! It's not possible!". After
explaining that it was indeed possible and that the code was in production,
they borrowed my listings "for more review".

 

[Roedy Green]

Assembler is like a bad power tool with _no_
safety features.

it made up for it was that tracing was feasible. I never published
any code I had not watched run over every instruction path. It was
very easy to interfere in the execution to exercise things.

You were like a watchful mother who knew what every last bit in your
program was doing. With high level languages so much goes on you are
only vaguely aware of.

In practice, it was relatively easy to put out 100% bug free code. On
the other hand, you never tackled really large projects.

 

[Roedy Green]

That's about equivalent to
your 122 opcodes for System/370 assembly, and far fewer than the typical
processor, as far as I can see.

Java's operators are very simple. Compare the quirkiness of the
"division" operator in a pentium. Some operators only work with
certain registers. Sometimes they give you a result that is easy for
the machine to compute, but not what you want in the general case.
Nothing happens automatically for your convenience. Every bit that
changes state you know about and have to control consciously. Often
the registers are too small and you somehow have to fake bigger ones.

There are the plethora of addressing modes, where you actually do
several mathematical operations in one instruction.

I greatly enjoy assembler programming, partly because you can touch
perfection. The joy in creating the optimal Java program is not as
acute since it is so far from the fastest possible program, just the
fastest possible Java program.

 

[Roedy Green]

I guess the real learning curve comes when you get around to
actually making it do something. Then when you add to that the ability to
do literally anything and there's very little to stop you...

Assembler is kind of like a jigsaw puzzle where all the pieces are so
small you have to handle them with tweezers.

 

[Robert B.]

it made up for it was that tracing was feasible. I never published
any code I had not watched run over every instruction path. It was
very easy to interfere in the execution to exercise things.

You were like a watchful mother who knew what every last bit in your
program was doing. With high level languages so much goes on you are
only vaguely aware of.

In practice, it was relatively easy to put out 100% bug free code. On
the other hand, you never tackled really large projects.

We tackled some huge projects. One project I worked on generated nearly 4mb
of executable code and that was an enhancement to massive application base!