Type Checking, C vs. Assembly, & other stuff


¬a/b wrote:
>
> Good routines should not have as the first shoot in
> "processor hardware" (speed) nor in "operating system" but
> *the first thing* is "minimize the chance of errors" and "find all in
> few routines"

This is why, for example, it's good to have an assembler perform type
checking on your source files. To help you minimize the chance of
errors. So the question I ask is "why do you disagree that an assembler
should check the types of the operands you feed to the instructions?"
(a comment you made in another thread)

>
> c is not superior, it allow to see different things
> but i think: with assembly i *see more*
> then assembly is superior in loops to every language i know
> people "if, while, for, etc" are all wrong,
> assembly jumps 'is the answer' :)

But what is the question? :-)

What makes one loop "superior" to another?
What makes one implementation of a loop superior to another? I'm sure
you can get a fair amount of disagreement on *whatever* answer you
supply to that question :-)


> >The cost depends on complexity of code and ASM is more complex than FORTRAN or
> >C.
>
> no assembly is more easy than C

Easier at what?
I think you'll find that most programmers disagree with such a generic
statement.

> the advantage of C is only that it is *more fast to write* especially
> fast in writing some routines that deal with array of chars,

Actually, dealing with arrays of characters is one thing that
*assembly* is pretty good at. But...

> and it
> have some very good library functions

And there is no reason you can't have a good library for assembly
programmers. Check out the MASM32 library, the UCR Standard Library for
80x86 Programmers, the HLA Standard Library, and dozens of other
assembly language libraries across the 'net.

Start here:

http://webster.cs.ucr.edu/AsmTools/MASM/MASMLibs.html

For the HLA Standard Library, look here:

http://webster.cs.ucr.edu/AsmTools/HLA/index.html

And various other assemblers also have their own set of library
routines.

>
> >fails to work with abstractions,
>
> it is false, assembly is for definition the low language
> any 'abstraction' should be not allowed
> if you like "abstractions" you can try c++

Not true.
Assemblers like MASM, TASM, and HLA provide lots of data and control
structure abstractions. When faced with this fact, most people who try
to complain that assembly provides no such abstractions try to wimp out
and claim that these products aren't assemblers. Silly argument.

>
> >lacks support for reliability or safety,
>
> it is false because assembly is easy to debug

Depends on who is doing the debugging, I guess.
I've been debugging a lot of programs over the years, and I've never
found assembly language to be easier to debug than HLL code. I've
certainly found it easier to use both (HLL) source code debugging and
disassembly listing when debugging HLL code, but debugging pure
assembly code generally isn't easier than debugging HLL code, and in
some cases I've found to to be *much* more difficult.


>
> >fails to keep up with computer technology,
>
> what is "keep up"?

What "The_Stooge" means here is that assembly languages aren't
advancing with new features like compiler are. However, when you
consider the assembly languages that *have* advanced, like MASM, TASM,
and HLA, "The_Stooge" simply exclaims that these are "high-level
languages" in order to rectify the problem with his argument.

Fine. MASM, TASM, and HLA are "high-level languages." So all the
benefits he is claiming for HLLs apply to MASM, TASM, and HLA.


>
> >lacks
> >appropriate engineering-based support tools and environments,
>
> it is false if you see Rosasm.

I'd be careful about using "Software engineering" and "RosAsm" in the
same sentence :-). Almost every major design decision in RosAsm is
based on Rene Tournois' inability to do proper software engineering.
Lack of library modules, the monolithic program approach, no support
for local symbols in macros, and on, and on, and on, are all examples
of features that are sadly lacking in RosAsm that serious software
engineers need.

Fortunately, whether or not "assembly language" and "software
engineering" are compatible doesn't rely upon the features of one tool.
For example, MASM combined with Visual Studio provides a
high-performance IDE, complete with editor, symbolic debugger,
profiler, project manager, and lots of other tools assembly programmers
might find useful. Then, of course, there are products such as RadAsm
and HIDE that also provide assembly-only IDEs.


> For me i don't need environments: only
> the Nasm assembler and my macro substitution program

Yes, the command-line is suitable for most people.

>
> >lacks clarity in the source code,
>
> assembly code that i write is clear like the sun to me

Code clarity is not based on how easy *you* find your code to read, but
how easy *others* find your code to be. This is why its a really bad
idea to use programming constructs like "mov eax, byteVariable". This
raises questions like "what is this guy thinking?" when someone else
reads your code. This is why, for example, that writing something like
"mov eax, dword ptr byteVar" is a *much* better idea -- it *tells*
whomever comes along that you *really did* intend to load the four
bytes at the address specified by a byte variable into the EAX
register. It's also why it's an even better idea to make a union
structure, to help prevent accidental modifications to the sequence of
data declarations you're loading into the EAX register (all of this is
from another thread, for those who are wondering).


>
> >lacks complexity management,
>
> it is false

Well, perhaps RosAsm does. Maybe even some of the other hobby-level
assemblers do. But assemblers like MASM, TASM, and HLA provide all
kinds of abstractions to management complexity. And most decent
assemblers provide good macro facilities, to let assembly programmers
extend the language and hide lots of unnecessary details, when
appropriate.

>
> >lacks straightfoward and user
> >friendly concurrency support,
>
> ?

Funny. I've created threads and processes in assembly language using
the same OS API calls (in Windows and Linux) that I've used in HLLs
like C/C++. Wasn't any less straight-forward or less user-friendly.

>
> >lacks distributed system support,
>
> ?

Funny, the same OS APIs...

>
> >has poor
> >maintainability,
>
> ?

Certainly there is the greater opportunity for writing sloppy code in
assembly than in a HLL. The example I keep coming back to, loading four
separate byte variables into EAX with a single mov instruction is a
classic example of a hack that produces code that is a pain in the ***
to maintain. But guess what? You can pull this same trick in C/C++ (and
many other HLLs) with the exact same consequences.

The problem with assembly language is that many assembly programmers
think it's okay to write code this way, and even argue that this is the
way it ought to be done. As long as assembly programmers continue to
write code in an undisciplined fashion (for no good reason other than
to save typing a few characters), people like "The_Stooge" will
continue to claim that assembly code has poor maintainability.


>
> >lacks true object-oriented programming support, lacks
> >portability, etc, etc, etc.
>
> these things are above repeat

"The_Stooge" refuses to accept that fact that TASM has supported
object-oriented programming for *well* over a decade (almost 15 years,
in fact). And HLA has provided object-oriented assembly programming
since 1999. Though MASM doesn't provide *great* support for OOP, many
MASM programmers have covered this omission by providing macro
libraries that provide *most* of the capabilities of "true"
object-oriented programming.

No doubt, "The_Stooge" will come back with comments about what is and
what is not "true" object-oriented programming; but he has completely
demonstrated his ignorance of this subject in the past (this is the guy
that argued that semicolons are optional at the end of statements in
the C language; he even made this claim after people on the C language
standards committee corrected him; clearly, he's just a troll and will
state obvious non-truths in order to get people worked up and going).


>
> >The point of a programming language to make it simple to transfer thoughts
> >from an idea to a program.
>
> no there is the only reason of *more fast to write*

Neither of the statements is correct. Though making it simple to
implement an idea is a good attribute of a programming language, this
is *not* the *point* of a programming language. And although it's nice
if a programming language makes it possible to quickly implement
solutions in that language, this is *not* the *point* of a programming
language. Programming languages are a compromise of many different
attributes. Sometimes you sacrifice some attributes to obtain others.

If you can only state one "point" for a programming language, that
point would have to be: "provide a way to compute the solution of a
(computable) problem on computer hardware." Everything else is just an
embellishment.


>
> >People do not think naturally in ASM and languages
> >that use unnatural terms and syntax are not productive...duh!
>
> there are fields where assembly is more natural *easy* and productive:
> for example define +*- != == etc or call functions or use stack
> or talk to hardware

People do not think naturally in *any* programming language.
They have to be trained. Indeed, the basic concept of an assignment
statement (probably the basis of the imperative programming language)
is foreign to most people. Anyone who has taught a beginning
programming class will certain attest to the fact that programming
languages are *not* natural.

>
> >>some time i see the NG: muc.lists.bugtraq
> >>do you know how many error they find?
> >
> >ASM is very conducive to creating bugs,
>
> yes but they are find soon

All programming languages are conducive to creating bugs. This is
because computers require a high level of precision and most people
are, quite frankly, quite sloppy.

As for finding bugs quickly -- far better to never have them in the
first place or to have the computer find them for you. This is why, for
example, it's a good idea to support type checking in an assembler. You
don't have to waste time finding bugs like "why did 'mov eax, byteVar'
work okay, but 'mov byteVar, eax' is crashing my system?"





>
> >hence the reason is was abadonded years ago as a primary language by all

Well, by most people, not by all :-)

>
> years ago, but not for me now

But you *are* in a very small minority. And despite what Rene Tournois
thinks, the world will not be switching, enmasse, to assembly language.
Ever.
Cheers,
Randy Hyde

.

Quantcast