From: usu...@euronet.nl (Technocrate)
Subject: Assembly vs c/c++
Date: 1996/11/15
Message-ID: <56iv2a$c1p@news.euro.net>#1/1
X-Deja-AN: 196875261
organization: EuroNet Internet
newsgroups: comp.lang.c++,comp.lang.c,comp.lang.asm.x86
I've been following the "what-is-the-best-language-discussion" between
the pro-Assembly programmers and pro-c/c++ programmers for a while now
and seen it developing in favour of c/c++ under the strong leadership
of alice.
alice makes some seemingly strong points in favour of c/c++ (and
condemns Assembly wholeheartedly as a programming language):
-lower development time
-higher readibility of source
-portability
-easier to learn than Assembly
-"c/c++ standard" vs lots-of-different-processors-Assembly-languages
-she claims to be able to let her computer do anything it's able to
by only using c/c++,so why use the harder Assembly?
The points she makes are strong from her point of view. But in defense
of Assembly (of any processor) I wish to add my viewpoint in these
matters.
But first:
I have the joy of programming in different languages for over 13 years
now :Basic ("who hasn't in those good ol'days,I'm not ashamed to admit
it"),Pascal...,Prolog,LISP (lost in stupid parentheses),SQL (I still
haven't figured out whether it's a real G4 language or a script for a
database),c/c++ (easy and fast) and last but not least:Assembly (and
in the good ol'days hand-poked machinecode) for the 6502 (look ma! no
registers),Z80 (a blessing in those days),68k (look ma! more registers
than a pentium) and x86 (no pro,haven't got no books about it,yet).
In my humble opinion the winners are Assembly and c/c++ for "general
programming " (which I most often do). No silly war here.
I use c/c++ most often when I want to produce simple algorithms in
short notice and I like the ease of programming in it.
I use Assembly when I want maximum performance,compact code and want
to do things that cannot be done in c/c++ (you see:I allready disagree
on one point alice makes).
Mostly,I just link'em up (hybrid programming).Leaving things as
user-interfaces, non-time-sensitive calculations,etc. to c/c++ and
doing stuff that has to be fast,be small or weird in Assembly.
Now I will comment the above points of alice (not the way she made
them!) to indicate a different approach to the hard,specialized
Assembly programming contra economy style c/c++:
-lower development time in c:true,but for the ones who program for the
sheer pleasure of it (squeezing out the highest performance or most
compact code) time is not an issue.
-higher readibility of source code in c:true,but what do you expect if
you program in the cpu's native tongue.It's SPORT to use our own
"fluid concepts and creative analogies" against the rigid predicate
logic of the "machine" to get the best (compilers are no match for an
Assembly wizard,parallel processing or not).Besides:what else are
comments for?
-portability of c/c++ better:well... okay but that ANSI stuff doesn't
do no windows or any other OS specific things and I believe many c
programmers who port programs find their int's 16 bit instead of 32 or
vice versa. Assembly isn't meant to provide portability,it's just
meant to make programs for a specific cpu (no fair). Besides:port to
what,only one major system for common use.
-c/c++ easier to learn than assembly: false,more basic than assembly
is hardly possible (logo?) and c/c++'s priorities of operators,
operator-overload (ha! + is now minus),MFC classes from a CD! ,the
workings of the compilers/source editors/linkers/optimize
settings,etc. aren't too easy (easier to learn about the chips in your
computer, let's go bad-mannered hardware!).In learning Assembly you
gain insight in the machine's workings (why i++ is faster than i+=1
for example). Nevertheless:I admit:Assembly is harder to PROGRAM in
(that's the challenge).
-c/c++ can make the computer do anything capable of:false : (unless
you use an inline assembler,but Hey! that's Assembly,no c/c++)
-processor instructions like HALT,VERR,WAIT
-undocumented instructions (really a rage for Z80)
-self-modifying programs (handy to compactisize your code)
-extreme optimizing with knowledge of instruction sizes and execution
times not known by straight c/c++ programmers.
I think Assembly and c/c++ are both okay.It's kindda unfair to condemn
Assembly (especially the way it's being condemned).It may seem
primitive but Assembly takes you closest to your machine
(okay,issueing highs/lows to the pins is even closer but that's no
language,that's masochism).
Peace to all Programmers! Keep Coding!
******
"Many were increasingly of the opinion that they'd all made a big
mistake in coming down from the trees in the first place.
And some said that even the trees had been a bad move,and that no one
should ever have left the ocean."
(Hitch hiker's guide to the Galaxy, Douglas Adams)
******
From: se...@solutions.solon.com (Peter Seebach)
Subject: Re: Assembly vs c/c++
Date: 1996/11/15
Message-ID: <56j1b5$59q@solutions.solon.com>#1/1
X-Deja-AN: 196756832
references: <56iv2a$c1p@news.euro.net>
organization: Usenet Fact Police (Undercover)
reply-to: se...@solon.com
newsgroups: comp.lang.c++,comp.lang.c,comp.lang.asm.x86
In article <56iv2a$c...@news.euro.net>, Technocrate <usu...@euronet.nl> wrote:
>-lower development time in c:true,but for the ones who program for the
>sheer pleasure of it (squeezing out the highest performance or most
>compact code) time is not an issue.
True. On the other hand, some of those who program for the sheer pleasure
of it are looking for other things. I enjoy having programs that compile with
no warnings or errors, and run as expected, on machines I've never heard of
before. I am pleased that my programs, developed invariably under Unix,
run without modification on my Mac and on a DOS box.
>-portability of c/c++ better:well... okay but that ANSI stuff doesn't
>do no windows or any other OS specific things and I believe many c
>programmers who port programs find their int's 16 bit instead of 32 or
>vice versa.
Which is why competent programmers isolate dependancies or eliminate them.
>Assembly isn't meant to provide portability,it's just
>meant to make programs for a specific cpu (no fair). Besides:port to
>what,only one major system for common use.
That major system is so important I don't even use it. Except as a curiosity.
The real world is driven by systems that are not remotely *similar* to the
PC.
The PC sucks; it's the least desirable platform I can imagine for development.
There's no OS to keep the machine from crashing. *NOTHING* I do wrong in
my development can crash my computer; this is as it should be. If my
program is buggy, my program is politely killed, and the system keeps right
on running.
Port to the Macintosh, the Amiga, 8 brands of Unix, NT, NT on the Alpha,
Linux, the new PPC-based Amiga... Port to everything, ideally. It's
a great game; you can get a new computer and double your speed without
touching a line of code.
>-c/c++ easier to learn than assembly: false,more basic than assembly
>is hardly possible (logo?) and c/c++'s priorities of operators,
>operator-overload (ha! + is now minus),MFC classes from a CD! ,the
>workings of the compilers/source editors/linkers/optimize
>settings,etc. aren't too easy (easier to learn about the chips in your
>computer, let's go bad-mannered hardware!).In learning Assembly you
>gain insight in the machine's workings (why i++ is faster than i+=1
>for example). Nevertheless:I admit:Assembly is harder to PROGRAM in
>(that's the challenge).
The operator overload stuff is C++; C is much simpler.
You make one of the strongest cases for avoiding assembly. What's this
nonsense about i++ being faster than i+=1? It may have been true on some
particularly lame compilers, but 99% of the C compilers out there produce
identical code.
More strange, someone timed them on Borland C and found that 'i=i+1' was
faster by about 25% than either of the obvious equivalents.
> -processor instructions like HALT,VERR,WAIT
You can't do those in assembly, either; get a real operating system.
> -undocumented instructions (really a rage for Z80)
Useless; the next processor won't have them, and all your code is worthless
until you rewrite it.
> -self-modifying programs (handy to compactisize your code)
Useless; they make your code run an order of magnitude slower, if it runs at
all, because they're incompatible with caching.
> -extreme optimizing with knowledge of instruction sizes and execution
> times not known by straight c/c++ programmers.
Yeah, but I bet you can't come within 10% of the speed of a Cray compiler.
I don't know a thing about instruction timing. I don't have to. The
*compiler* knows quite a lot, and will make those decisions for me. If
it's a good compiler (I don't know of one for the 80x86), it'll make them
well enough that it's not feasible for me to compete with it.
>I think Assembly and c/c++ are both okay.It's kindda unfair to condemn
>Assembly (especially the way it's being condemned).It may seem
>primitive but Assembly takes you closest to your machine
>(okay,issueing highs/lows to the pins is even closer but that's no
>language,that's masochism).
Right. Why on earth would I want to be close to the machine? I'm using
this box to *do* things. I want to be close to the *problem*, not the
tool. Do you garden more effectively thinking about plants, or thinking about
the spade?
-s
--
Peter Seebach - se...@solon.com - Copyright 1996 - http://www.solon.com/~seebs
Unix/C Wizard - send mail for help, or send money for consulting!
The *other* C FAQ, the hacker FAQ, et al. See web page above.
Unsolicited email (junk mail and ads) is unwelcome, and will be billed for.
From: Graham Hughes <graham...@resnet.ucsb.edu>
Subject: Re: Assembly vs c/c++
Date: 1996/11/16
Message-ID: <56jqnl$due@yuggoth.ucsb.edu>#1/1
X-Deja-AN: 196818194
references: <56iv2a$c1p@news.euro.net> <56j1b5$59q@solutions.solon.com>
organization: University of California, Santa Barbara
newsgroups: comp.lang.c++,comp.lang.c,comp.lang.asm.x86
-----BEGIN PGP SIGNED MESSAGE-----
se...@solutions.solon.com (Peter Seebach) writes:
>The PC sucks; it's the least desirable platform I can imagine for development.
>There's no OS to keep the machine from crashing. *NOTHING* I do wrong in
>my development can crash my computer; this is as it should be. If my
>program is buggy, my program is politely killed, and the system keeps right
>on running.
Just a request; realize that PC/Win and PC/Linux are totally different
beasts. While the x86 is not the best for a Unixy type of OS, Linux
runs quite happily on it. I do all my coding these days in gcc, usually
through a telnet connection on the other side of campus. I figure I
turned my simple, primitive 486-100 into a workstation through the
installation of some software. It constantly amuses me that people
insist that "Oh, you need a Pentium to do anything" when anything they
try I can do (faster) on a two year old machine.
I totally agree with you if the reference "OS" is Windows. Linux is a
different story.
> If
>it's a good compiler (I don't know of one for the 80x86), it'll make them
>well enough that it's not feasible for me to compete with it.
Do you consider gcc a good compiler? It's the only thing I use these
days.
>Right. Why on earth would I want to be close to the machine? I'm using
>this box to *do* things. I want to be close to the *problem*, not the
>tool. Do you garden more effectively thinking about plants, or thinking about
>the spade?
I actually experienced this a while ago; I used to hack assembler when
all I had was an 80188 laptop. Yes, you've probably never heard of it.
I actually managed to shoehorn an ANSI C compiler onto two 720K disks
for that machine, but it just wasn't worth the time to hack C.
Now, I don't *understand* protected mode assembler, let alone the ELF
variety. I stick with C and C++, and let gcc do my work for me. Plus,
the code runs the same in the Suns down the hall :)
- --
Graham Hughes (graham...@resnet.ucsb.edu)
http://A-abe.resnet.ucsb.edu/~graham/ for HTML
``Unix is many things to many people, but | finger graham@A-abe.resnet
it's never been everything to anybody.'' | for PGP key
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMo1usiqNPSINiVE5AQHw3gP+PLhPBPcB+eDjg/YcldvSrKU+xA0NE7nF
J3OPl/X8uwnfDhFii7dGf7RICzsLVFgrye0xYuCKKAvqRGZ7GBloOwy8j3F+psCR
3masuob7h0Eo8Hm2K0O3focXtQiGpS/jPFtcStb2BQExtK1ymsjRQKnOgnvxBjxO
ywarCCKj2PU=
=EDE4
-----END PGP SIGNATURE-----
From: r...@sunspot.tiac.net (Robert Krawitz)
Subject: Re: Assembly vs c/c++
Date: 1996/11/16
Message-ID: <56kk60$8r@news-central.tiac.net>#1/1
X-Deja-AN: 196871627
references: <56iv2a$c1p@news.euro.net> <56j1b5$59q@solutions.solon.com>
organization: The Internet Access Company, Inc.
newsgroups: comp.lang.c++,comp.lang.c,comp.lang.asm.x86
In article <56jqnl$d...@yuggoth.ucsb.edu>
Graham Hughes <graham...@resnet.ucsb.edu> writes:
se...@solutions.solon.com (Peter Seebach) writes:
>The PC sucks; it's the least desirable platform I can imagine for development.
>There's no OS to keep the machine from crashing. *NOTHING* I do wrong in
>my development can crash my computer; this is as it should be. If my
>program is buggy, my program is politely killed, and the system keeps right
>on running.
Just a request; realize that PC/Win and PC/Linux are totally different
beasts. While the x86 is not the best for a Unixy type of OS, Linux
runs quite happily on it.
Linux on my PC (a very early P90) blasts along. It makes my Sparc 10
at work look like something the cat brought in by comparison. Even
with somewhat less memory than my Sparc, it runs rings around it.
For that matter, the Linux kernel can recover nicely from quite a few
*kernel* errors. The kernel tries very hard not to die even when a
bad memory access is made, for example. To this extent, it's a more
robust than most other Unix OS's.
--
Robert Krawitz <r...@tiac.net> http://www.tiac.net/users/rlk/
Member of the League for Programming Freedom -- mail l...@uunet.uu.net
Tall Clubs International -- http://www.tall.org/ or 1-800-521-2512
From: "Dennis Weldy" <dmw...@ingr.com>
Subject: Re: Assembly vs c/c++
Date: 1996/11/16
Message-ID: <01bbd3ee$698bd6f0$12938781@weldypc>#1/1
X-Deja-AN: 196907800
references: <56iv2a$c1p@news.euro.net>
organization: Intergraph
newsgroups: comp.lang.c++,comp.lang.c,comp.lang.asm.x86
> -c/c++ easier to learn than assembly: false,more basic than assembly
> is hardly possible (logo?) and c/c++'s priorities of operators,
> operator-overload (ha! + is now minus),MFC classes from a CD! ,the
> workings of the compilers/source editors/linkers/optimize
> settings,etc. aren't too easy (easier to learn about the chips in your
> computer, let's go bad-mannered hardware!).In learning Assembly you
> gain insight in the machine's workings (why i++ is faster than i+=1
> for example). Nevertheless:I admit:Assembly is harder to PROGRAM in
> (that's the challenge).
Ok, granted assembly is elementary. They have lots of little tools, all
alike (to a novice) now put 'em together to do something. Thats much
harder.
Since learning the language and programming in it go hand in hand, don't
you prove her point? :-)
>
> -c/c++ can make the computer do anything capable of:false : (unless
> you use an inline assembler,but Hey! that's Assembly,no c/c++)
> -processor instructions like HALT,VERR,WAIT
> -undocumented instructions (really a rage for Z80)
> -self-modifying programs (handy to compactisize your code)
Most modern architectures prevent one from self-modifying code
(thankfully).
This makes the code non-reentrant. generally not a good thing on
multitasking systems.
Sides, at a former job someone had written a program which modified itself
at run-time. Took someone who was trying to modify the thing several days
to see what was going on under the different conditions.
> -extreme optimizing with knowledge of instruction sizes and execution
> times not known by straight c/c++ programmers.
>
> I think Assembly and c/c++ are both okay.It's kindda unfair to condemn
> Assembly (especially the way it's being condemned).It may seem
> primitive but Assembly takes you closest to your machine
> (okay,issueing highs/lows to the pins is even closer but that's no
> language,that's masochism).
>
Well said. Theres a place for assembly, c, heck, even goto. :-)
// maybe I shouldn't add that, start ANOTHER thread...
Why is it that several compilers allow you to embed assemby in the C file?
because its USEFUL :-)
From: "Dann Corbit" <a-c...@microsoft.com>
Subject: Re: Assembly vs c/c++
Date: 1996/11/16
Message-ID: <01bbd3aa$e4232470$2dac399d@a-cnadc1>#1/1
X-Deja-AN: 196786775
references: <56iv2a$c1p@news.euro.net>
content-type: text/plain; charset=ISO-8859-1
organization: Microsoft Corp.
mime-version: 1.0
newsgroups: comp.lang.c++,comp.lang.c,comp.lang.asm.x86
Technocrate <usu...@euronet.nl> wrote in article <56iv2a$c...@news.euro.net>...
[snip]
> -lower development time in c:true,but for the ones who program for the
> sheer pleasure of it (squeezing out the highest performance or most
> compact code) time is not an issue.
For those who pay for your time, it is an issue.
> -higher readibility of source code in c:true,but what do you expect if
> you program in the cpu's native tongue.It's SPORT to use our own
> "fluid concepts and creative analogies" against the rigid predicate
> logic of the "machine" to get the best (compilers are no match for an
> Assembly wizard,parallel processing or not).Besides:what else are
> comments for?
Is it SPORT to maintain something that is less readable?
> -portability of c/c++ better:well... okay but that ANSI stuff doesn't
> do no windows or any other OS specific things and I believe many c
> programmers who port programs find their int's 16 bit instead of 32 or
> vice versa.
Granted, ANSI C "doesn't do Windows" but C compilers add
extensions for every OS I've ever used. And all of the service routines
written in ANSI C work on everything.
> Assembly isn't meant to provide portability,it's just
> meant to make programs for a specific cpu (no fair). Besides:port to
> what,only one major system for common use.
Really? Which one is it? My time is largely divided between Windows
NT and VMS, but there are huge corporations that run on UNIX, or MVS
or ...
> -c/c++ easier to learn than assembly: false,more basic than assembly
> is hardly possible (logo?) and c/c++'s priorities of operators,
> operator-overload (ha! + is now minus),MFC classes from a CD! ,the
> workings of the compilers/source editors/linkers/optimize
> settings,etc. aren't too easy (easier to learn about the chips in your
> computer, let's go bad-mannered hardware!).
To learn a single Assembly language is easier than C, but it is a lot
easier to learn C than to learn ALL AVAILABLE Assembly language
platforms.
> In learning Assembly you
> gain insight in the machine's workings (why i++ is faster than i+=1
> for example). Nevertheless:I admit:Assembly is harder to PROGRAM in
> (that's the challenge).
Depends on the task whether it is harder or easier. And i++ is the
exact same speed as i = i + 1 or i += 1 on any half-decent compiler
(as long as optimization is not disabled).
> -c/c++ can make the computer do anything capable of:false : (unless
> you use an inline assembler,but Hey! that's Assembly,no c/c++)
> -processor instructions like HALT,VERR,WAIT
> -undocumented instructions (really a rage for Z80)
> -self-modifying programs (handy to compactisize your code)
> -extreme optimizing with knowledge of instruction sizes and execution
> times not known by straight c/c++ programmers.
You missed the whole point here. Some instructions and particular
techniques may be missing, but you can accomplish the same TASKS
without resorting to Assembly. There are some tasks that are better
left to Assembly language, but they can be programmed in any language
(even BASIC or COBOL).
> I think Assembly and c/c++ are both okay.It's kindda unfair to condemn
> Assembly (especially the way it's being condemned).It may seem
> primitive but Assembly takes you closest to your machine
> (okay,issueing highs/lows to the pins is even closer but that's no
> language,that's masochism).
Anyone who condemns Assembly is an idiot. Assembly is a useful
tool. Most of the C compilers we use to program in C are written at
least partially in Assembly language. Everyone who is a real craftsperson
knows how to use all of their tools to their best advantage.
Most C programmers that I know also know Assembly language.
From: Alicia Carla Longstreet <ca...@ici.net>
Subject: Re: Assembly vs c/c++
Date: 1996/11/17
Message-ID: <328FEB9B.6390@ici.net>#1/1
X-Deja-AN: 197153282
references: <56iv2a$c1p@news.euro.net> <01bbd3ee$698bd6f0$12938781@weldypc>
content-type: text/plain; charset=us-ascii
organization: The Computer Solution
mime-version: 1.0
reply-to: ca...@ici.net
newsgroups: comp.lang.c++,comp.lang.c,comp.lang.asm.x86
x-mailer: Mozilla 3.0Gold (Win95; I)
Dennis Weldy wrote:
>
>> -c/c++ easier to learn than assembly: false,more basic than assembly
>> is hardly possible (logo?) and c/c++'s priorities of operators,
>> operator-overload (ha! + is now minus),MFC classes from a CD! ,the
>> workings of the compilers/source editors/linkers/optimize
>> settings,etc. aren't too easy (easier to learn about the chips in your
>> computer, let's go bad-mannered hardware!).
How much of this would you actually try to teach in a
for-the-very-first-time programming class, I wouldn't try to teach any
of it.
Bottom line: How long would you need to spend, in a classroom, to teach
the mechanics of loop in assembler. Remember, your objective is to
teach about the concept of looping in computer programs. You have
several different types of loops to teach:
Loops where the extression is tested at the top of the loop, at the
bottom of the loop, and fixed length loops. In one semester you have 60
45 minute classroom periods to teach the basics of programming. Take
out time for tests, test discussions, test preparation (the discussion
before the test), school assemblies, and other interruptions, you end up
with about 45 45 minute classroom periods. Further, breaks, late
entries, and the time students use to get ready to rush out into the
hallway to meet firends will reduce that to about 40 minutes. This is
not a whole lot of time to teach the subject.
Considering what you have to teach, I would have to say that you can't
afford to spend more that 9 lectures on loops or three lectures for each
type of loop. Of that time you simply cannot spend more that 15 to 20
minutes on the mechanics of each loop type, can you do that in
assembler, with teenagers who know NOTHING about programming. In 'C' I
can do it easily, in fact, in about 15 minutes for the first one and 5
minutes for each subsequent one. To make assembler equal to 'C' you
would need to match this, to make it better for teaching you would need
to improve on it. If I recall, it took me longer than that to learn the
mechanics of loops in assembler and I knew how to program!!!!
BTW, with 'C' I deal with editors, compilers, linkers, optimize setting,
and all that wonderful stuff. Of course, the optimization and other
setting/switches wouldn't even begin to be taught to beginning
programmers, so we are dealing with the Edit/Compile/Link/Test cycle.
In Assembler we have the Edit/Assemble/Link/Test cycle, is this easier?
BTW, the 'C' compiler I use to teach 'C' has a /e switch to
automatically link the students program, so I can reduce it to
Edit/CompileLink/Test cycle.
Oh yes, I have considered the A86 assembler, and it is a serious
contender. No directives, automatic assembly to a .com, but I still
believe assembler is too complex to use to teach basic programming
skills to teenagers.
> > In learning Assembly you gain insight in the machine's workings
> > (why i++ is faster than i+=1 for example).
Agreed, but the insight only comes when you learn the other language!
> > Nevertheless: I admit: Assembly is harder to PROGRAM in (that's
> > the challenge).
Wouldn't that make learning to program in assembler harder also. Back
to basics: The question is: Which language is best for teaching
programmer-to-be's.
Remember, when most of you learned assembler you already KNEW how to
program, you were, essentially, just learning a new syntax. Knowing the
elements of programming in one language made learning assembler MUCH
easier that it would have been if you didn't already know how to
program. That is, of course, my entire point.
Alicia Carla Longstreet
From: usu...@euronet.nl (Technocrate)
Subject: Re: Assembly vs c/c++
Date: 1996/11/18
Message-ID: <56ofj6$er0@news.euro.net>#1/1
X-Deja-AN: 197124731
references: <56iv2a$c1p@news.euro.net> <01bbd3aa$e4232470$2dac399d@a-cnadc1>
organization: EuroNet Internet
newsgroups: comp.lang.c++,comp.lang.c,comp.lang.asm.x86
"Dann Corbit" <a-c...@microsoft.com> wrote:
>> Assembly isn't meant to provide portability,it's just
>> meant to make programs for a specific cpu (no fair). Besides:port to
>> what,only one major system for common use.
>Really? Which one is it? My time is largely divided between Windows
>NT and VMS, but there are huge corporations that run on UNIX, or MVS
>or ...
>
My fault,as a "bad-mannered" Assembly programmer I erronously used
"system" to refer to the glorified xt (with a nowadays much too fast
cpu in it that it needs a built-in cachememory) instead of the cpu/OS.
>> In learning Assembly you
>> gain insight in the machine's workings (why i++ is faster than i+=1
>> for example). Nevertheless:I admit:Assembly is harder to PROGRAM in
>> (that's the challenge).
>Depends on the task whether it is harder or easier. And i++ is the
>exact same speed as i = i + 1 or i += 1 on any half-decent compiler
>(as long as optimization is not disabled).
>
Okay,I've given a weak example here but try this one:
a=(a<<3)+(a<<1); instead of a*=10;
I wonder whether your compiler tries to unravel multiplications or
divisions to bitshifts if that's faster (if there's a need for speed
at the cost of memory,although memory isn't an item if I look at the
size of nowadays programs on the pc). A single track c/c++ programmer
probably doesn't know the execution time differences between shifts
and multiplications/divisions.
>> -c/c++ can make the computer do anything capable of:false : (unless
>> you use an inline assembler,but Hey! that's Assembly,no c/c++)
>> -processor instructions like HALT,VERR,WAIT
>> -undocumented instructions (really a rage for Z80)
>> -self-modifying programs (handy to compactisize your code)
>> -extreme optimizing with knowledge of instruction sizes and execution
>> times not known by straight c/c++ programmers.
>You missed the whole point here. Some instructions and particular
>techniques may be missing, but you can accomplish the same TASKS
>without resorting to Assembly. There are some tasks that are better
>left to Assembly language, but they can be programmed in any language
>(even BASIC or COBOL).
Yeah,re-compiling at runtime? Calling non-ansi functions to halt the
processor? Accessing hardware via slow non-ansi functions while doing
a time sensitive job (microseconds stuff)?
>Anyone who condemns Assembly is an idiot. Assembly is a useful
>tool. Most of the C compilers we use to program in C are written at
>least partially in Assembly language. Everyone who is a real craftsperson
>knows how to use all of their tools to their best advantage.
>Most C programmers that I know also know Assembly language.
I wholeheartedly agree
From: se...@solutions.solon.com (Peter Seebach)
Subject: Re: Assembly vs c/c++
Date: 1996/11/17
Message-ID: <56oknv$7at@solutions.solon.com>#1/1
X-Deja-AN: 197138668
references: <56iv2a$c1p@news.euro.net> <01bbd3aa$e4232470$2dac399d@a-cnadc1>
<56ofj6$er0@news.euro.net>
organization: Usenet Fact Police (Undercover)
reply-to: se...@solon.com
newsgroups: comp.lang.c++,comp.lang.c,comp.lang.asm.x86
In article <56ofj6$e...@news.euro.net>, Technocrate <usu...@euronet.nl> wrote:
>My fault,as a "bad-mannered" Assembly programmer I erronously used
>"system" to refer to the glorified xt (with a nowadays much too fast
>cpu in it that it needs a built-in cachememory) instead of the cpu/OS.
Right. Which was his point; this system is utterly useless for serious
work, and I have about a dozen computers, none of which are that kind
of box. So, for me, yes, portability *is* an issue. I buy thousands
of dollars worth of software for platforms other than the PC, in all its
guises, and about $100-200 in the last year for the PC.
>Okay,I've given a weak example here but try this one:
>a=(a<<3)+(a<<1); instead of a*=10;
Dolt.
I have a system on which it's faster to use
a = (a << 3) + a + a;
...
But, of course, the *compiler* does that. I write 'i *= 10;'.
>I wonder whether your compiler tries to unravel multiplications or
>divisions to bitshifts if that's faster (if there's a need for speed
>at the cost of memory,although memory isn't an item if I look at the
>size of nowadays programs on the pc).
It does, *if* it's faster. In fact, it figures out how many shifts would
be faster than how many multiplies, and works it out; it may do part of the
operation with shifts folllowed by a multiply. On machines with enough
registers, more complicated values (look closely at doing i *= 191 some
time) may take up three registers during computation.
Or they may not if multiplication is faster.
>A single track c/c++ programmer
>probably doesn't know the execution time differences between shifts
>and multiplications/divisions.
Certainly. And you expect me to believe that you do? Not bloody likely.
Think about the dual execution and other such features of modern 80x86's,
let alone the completely different timing of real CPU's. Then try to
tell me with a straight face that you can meaningfully know the answer.
I know my compiler does it right; I've read the code it uses to do the
decisions, and it would take me about half an hour to do it by hand for
any one CPU for a reasonable range of multipliers; by contrast, it can do
all four of the CPU's I use, including the subtly different timings between
the '020 and the '040, in less than a second. (On my fast machine, in
less than a millisecond, probably.)
>Yeah,re-compiling at runtime?
Sheer idiocy; sort of a neat concept back in the heyday of the 6502, but
now sheer idiocy. *Think* about the word "cache".
>Calling non-ansi functions to halt the
>processor?
If the program loader lets you do this, get a real OS.
>>Anyone who condemns Assembly is an idiot. Assembly is a useful
>>tool. Most of the C compilers we use to program in C are written at
>>least partially in Assembly language.
I haven't even heard of a C compiler in use since 1972 or so which had
so much as a scrap of assembly in it. They're written in C.
>>Everyone who is a real craftsperson
>>knows how to use all of their tools to their best advantage.
True. Assembly is most often not even a tool, it's just the lack of a
tool. (*most often*. Not always; why, just two or three weeks ago I saw
some assembly that was written for a good reason.)
-s
--
Peter Seebach - se...@solon.com - Copyright 1996 - http://www.solon.com/~seebs
Unix/C Wizard - send mail for help, or send money for consulting!
The *other* C FAQ, the hacker FAQ, et al. See web page above.
Unsolicited email (junk mail and ads) is unwelcome, and will be billed for.
From: Alicia Carla Longstreet <ca...@ici.net>
Subject: Re: Assembly vs c/c++
Date: 1996/11/18
Message-ID: <328FEED9.1678@ici.net>#1/1
X-Deja-AN: 197155578
references: <56iv2a$c1p@news.euro.net> <56j1b5$59q@solutions.solon.com>
<01bbd3f0$91aee2b0$12938781@weldypc> <56nrp3$oe8@mujibur.inmind.com>
content-type: text/plain; charset=us-ascii
organization: The Computer Solution
mime-version: 1.0
reply-to: ca...@ici.net
newsgroups: comp.lang.c++,comp.lang.c,comp.lang.asm.x86
x-mailer: Mozilla 3.0Gold (Win95; I)
Linux has been around for... How many years? Linux is based on UNIX
which has been aroung=d for... How many years?
Almost any flavor of UNIX is superior as a development platform that the
relatively new protected mode OS's (Win NT has been around for about 3
ro 4 years, Win 95 has been around for only 1 year). Is it fair to
compare OS's that have been in place and debugged to virtually brand new
operating systems. Why don't you compare the first release of Linux to
Windows 95 or Windows NT, or the first release of UNIX.
And if you are going to trash platforms, the next version of MacOS is
actually supposed to have protection.
Linux is a freeware version of UNIX, as such it is not the development
platform of choice for most for-profit companies, further it is not the
OS of choice for the majority of users either. Those of us who work in
a capitalistic environment don't usually get to choose our development
environment. Windows 95 may not stack up to UNIX/Linux standards but it
is a WHALE of a lot better than DOS, Win3.x/DOS, or even
Win32s/Win3.x/DOS, and those of us who can afford/get to use Windows NT
are luckier still.
Alicia Carla Longstreet
P.S. I am not proud of it, but I managed to crash a Compaq 386 running
SCO Unix once. I have been working in Windows 95 for almost a year now
and I haven't crashed it once. This is more of a tribute to my improved
programming than the OS.
From: usu...@euronet.nl (Technocrate)
Subject: Re: Assembly vs c/c++
Date: 1996/11/18
Message-ID: <56ou7o$hgi@news.euro.net>#1/1
X-Deja-AN: 197160696
references: <56iv2a$c1p@news.euro.net>
<01bbd3aa$e4232470$2dac399d@a-cnadc1> <56ofj6$er0@news.euro.net>
<56oknv$7at@solutions.solon.com>
organization: EuroNet Internet
newsgroups: comp.lang.c++,comp.lang.c,comp.lang.asm.x86
se...@solutions.solon.com (Peter Seebach) wrote:
>I have a system on which it's faster to use
> a = (a << 3) + a + a;
>...
>But, of course, the *compiler* does that. I write 'i *= 10;'.
>It does, *if* it's faster. In fact, it figures out how many shifts would
>be faster than how many multiplies, and works it out; it may do part of the
>operation with shifts folllowed by a multiply. On machines with enough
>registers, more complicated values (look closely at doing i *= 191 some
>time) may take up three registers during computation.
Okay,so you've got a nice compiler..... Let's have another little try:
a=((!(b?(c?TRUE:FALSE):TRUE) && !(!b?(c||d?TRUE:FALSE):TRUE)))?
(!c?(d?TRUE:FALSE):TRUE):TRUE)?20:30
Turns your compiler this into the code to simply load "a" (whatever
memorylocation or register "a" might be) with 20 without the ability
to predict the contents of b,c or d?
If so,then I really like to have it coz I think this predicate logic
stuff is pretty dull.
>>A single track c/c++ programmer
>>probably doesn't know the execution time differences between shifts
>>and multiplications/divisions.
>Certainly. And you expect me to believe that you do? Not bloody likely.
Please,pay attention.I allready stated that shifts and additions are
in some cases faster than a multiplication.Just look them up,they're
in the book about the processor.
>Think about the dual execution and other such features of modern 80x86's,
>let alone the completely different timing of real CPU's. Then try to
>tell me with a straight face that you can meaningfully know the answer.
I can tell you with a straight face I COULD but I WOULDN'T for that's
the reason we have computers.And if your compiler could figure out how
to streamline the code for these fancy x86's then my assembler could
as well.
>>Yeah,re-compiling at runtime?
>Sheer idiocy; sort of a neat concept back in the heyday of the 6502, but
>now sheer idiocy. *Think* about the word "cache".
What about the cache? Having troubles with it?
>>>Everyone who is a real craftsperson
>>>knows how to use all of their tools to their best advantage.
>True. Assembly is most often not even a tool, it's just the lack of a
>tool. (*most often*. Not always; why, just two or three weeks ago I saw
>some assembly that was written for a good reason.)
Wellwell, I can see you're frustrated not having mastered the skill of
Assembly programming. You're convinced your compiler can produce
better code than you or anyone else can. Well,speak for yourself!
It's true I more often use c/c++ to program in than Assembly but
that's for the ease of it. When I feel the need to go down and dirty
with the assembler I WILL produce faster or more compact code than my
compiler is able to. Perhaps you have a compiler that exceeds your
limitations in Assembly programming. In that case you should stick to
it.
Greetings!
From: se...@solutions.solon.com (Peter Seebach)
Subject: Re: Assembly vs c/c++
Date: 1996/11/18
Message-ID: <56ovi5$90q@solutions.solon.com>#1/1
X-Deja-AN: 197163132
references: <56iv2a$c1p@news.euro.net> <56ofj6$er0@news.euro.net>
<56oknv$7at@solutions.solon.com> <56ou7o$hgi@news.euro.net>
organization: Usenet Fact Police (Undercover)
reply-to: se...@solon.com
newsgroups: comp.lang.c++,comp.lang.c,comp.lang.asm.x86
In article <56ou7o$h...@news.euro.net>, Technocrate <usu...@euronet.nl> wrote:
>Okay,so you've got a nice compiler..... Let's have another little try:
>a=((!(b?(c?TRUE:FALSE):TRUE) && !(!b?(c||d?TRUE:FALSE):TRUE)))?
> (!c?(d?TRUE:FALSE):TRUE):TRUE)?20:30
>Turns your compiler this into the code to simply load "a" (whatever
>memorylocation or register "a" might be) with 20 without the ability
>to predict the contents of b,c or d?
No. It complains that the parens don't match.
If I start that with
a=(((
I get
_main:
pea a6@
movel sp,a6
movel d2,sp@-
jbsr ___main
clrl _b.5
moveq #20,d2
and the constant 30 doesn't occur in the output. The remainder of the
code is just the loops, because I put it inside
for (b = 0; b < 2; ++b)
for (c = 0; c < 2; ++c)
for (d = 0; d < 2; ++d)
(No, it doesn't realize it could just iterate 8 times.)
But it *does* just shove 20 in there and ignore the 30 entirely. The entire
output code contains no 30, nor anything that I can find equivalent to it.
Neat, huh?
>If so,then I really like to have it coz I think this predicate logic
>stuff is pretty dull.
gcc. Free everywhere.
>>Certainly. And you expect me to believe that you do? Not bloody likely.
>Please,pay attention.I allready stated that shifts and additions are
>in some cases faster than a multiplication.Just look them up,they're
>in the book about the processor.
Yes, in *some cases*. Can you tell me, right now, whether a shift is
faster than a multiply? No. You have to look it up case by case, processor
by processor. My computer does that so I don't have to.
>I can tell you with a straight face I COULD but I WOULDN'T for that's
>the reason we have computers.And if your compiler could figure out how
>to streamline the code for these fancy x86's then my assembler could
>as well.
But you wouldn't *want* an assembler to; the entire point of assembler is
minute control over the processor.
>>>Yeah,re-compiling at runtime?
>>Sheer idiocy; sort of a neat concept back in the heyday of the 6502, but
>>now sheer idiocy. *Think* about the word "cache".
>What about the cache? Having troubles with it?
Yes. It tends not to like self-modifying code.
>>True. Assembly is most often not even a tool, it's just the lack of a
>>tool. (*most often*. Not always; why, just two or three weeks ago I saw
>>some assembly that was written for a good reason.)
>Wellwell, I can see you're frustrated not having mastered the skill of
>Assembly programming. You're convinced your compiler can produce
>better code than you or anyone else can. Well,speak for yourself!
It clearly outperforms your expectations (I'm assuming you thought the
trivial ?: test was hard) and it's free. Good commercial ones might be
better.
I'm completely unbothered by not knowing assembly. I don't *need* to know
it. It would only slow me down.
-s
--
Peter Seebach - se...@solon.com - Copyright 1996 - http://www.solon.com/~seebs
Unix/C Wizard - send mail for help, or send money for consulting!
The *other* C FAQ, the hacker FAQ, et al. See web page above.
Unsolicited email (junk mail and ads) is unwelcome, and will be billed for.
From: usu...@euronet.nl (Technocrate)
Subject: Re: Assembly vs c/c++
Date: 1996/12/03
Message-ID: <57vvkj$kk1@news.euro.net>#1/1
X-Deja-AN: 201987227
references: <56iv2a$c1p@news.euro.net> <57cv40$hs5@news.euro.net>
<57df45$9ms@solutions.solon.com> <57f5pu$h7h@news.euro.net>
<57gh3m$15c@solutions.solon.com> <57hfkh$fgd@news.euro.net>
<57uvau$48a@news1.mnsinc.com>
organization: EuroNet Internet
newsgroups: comp.lang.c++,comp.lang.c,comp.lang.asm.x86
>This, I believe, was Peter's point. Corrections to what I say are
>welcome, but continued arguments for argument's sake will be ignored.
RAAAH! [ censored out ] #@?!%* [moderater:I'm warning you again
usurper, one other such an outburst and I have you excommunicated by
the Pope himself]
Look here! The only point Seebach's making is showing how totally
irritating narrow pointed he can get as a self proclaimed C wizard.
My _humble_ points OTOH are:
1-There are things you can do in Asm and not in C
2-A good Assembly programmer can make programs which are AT LEAST as
fast as a C program.
3-Assembly and C/C++ should be used in conjunction for the best
performance (that is speed).
I replied to a challenge for Scott Nudds who (totally incorrectly
IMHO) stated that he could outperform *ANY* C/C++ program by a factor
of two.
Since I got irritated by the myriads of attacks on Assembly and I
didn't want S.N. to mess up in favor of C/C++ I myself replied and
my program was far faster and smaller than the Ansi C,not so Ansi C
and even the crippled Asm program.
It was a low dirty "I don't care about OS" program and demonstrated
the above points #1 and #2.It couldn't be done in C and it was far
faster and smaller.
Nobody could or would bring up something against my speedy,compact
program except for that *?#$!! [moderator: Okay usurper,the Pope says
you're in Limbo for at least 100 years!] Seebach.
First he stated the code was crippled,then he stated his computer
didn't have a parallel port and finally he stated the only x86 he had
was a router! (this took about dozen postings and got me at #8 at the
posters ranks and Seebach at #7).
My last resort was to rip out his boot rom to make it work,the program
on the replacement could be the same program! Still running and still
inexpressible in C! (you should have seen its face when I did this!)
I WON!! and I haven't seen Seebach here anymore although he has the
nasty habit humilliating me when I help some poor wandering newbie but
drop on some small philosophical syntaxical item on C which doesn't
matter anyway (Seebach's with some ... comittee).
You obviously only read the last posts between Seebach and me and were
shocked by the ridiculous contents it had been growing to.
I can only hope you could grasp why I had to go this low
You see:my very first posting to these newsgroups has been a plee for
peace between C/C++ and Assembly (I myself program in all three of
them).Reluctantly I have it seen growing to be the third largest
thread.
All I want is peace *really*,and for Seebach:well...I have his *&$%^!
[moderator:the Pope says he'll enjoy seeing you burning in Hell!] for
breakfast!
C Ya
From: se...@solutions.solon.com (Peter Seebach)
Subject: Re: Assembly vs c/c++
Date: 1996/12/03
Message-ID: <58187o$ce0@solutions.solon.com>#1/1
X-Deja-AN: 202083756
references: <56iv2a$c1p@news.euro.net> <57hfkh$fgd@news.euro.net>
<57uvau$48a@news1.mnsinc.com> <57vvkj$kk1@news.euro.net>
organization: Usenet Fact Police (Undercover)
reply-to: se...@solon.com
newsgroups: comp.lang.c++,comp.lang.c,comp.lang.asm.x86
In article <57vvkj$k...@news.euro.net>, Technocrate <usu...@euronet.nl> wrote:
>Look here! The only point Seebach's making is showing how totally
>irritating narrow pointed he can get as a self proclaimed C wizard.
No, my point is that your program does not do what you say it does. It
cannot be caused to run on any computer I own, and you would not be able
to get it to run on the one 80x86 I have regular access to.
>1-There are things you can do in Asm and not in C
Yes. Your program is one of them. Notable is that your program is orders
of magnitude less useful than one which runs under an OS.
>2-A good Assembly programmer can make programs which are AT LEAST as
>fast as a C program.
Only by using compiler output in some cases.
>3-Assembly and C/C++ should be used in conjunction for the best
>performance (that is speed).
Here is where you fall down; you simply haven't got the experience with the
systems where that simply isn't true.
There are cases where it's simply not possible to usefully improve on
something through assembly tuning. Adding a variable to a routine in C may
not only allocate one register differently, but may move something else from
being an address register to being a data register used as an offset from
a different address register. You simply can't usefully write your own
routines which blend with this.
>Since I got irritated by the myriads of attacks on Assembly and I
>didn't want S.N. to mess up in favor of C/C++ I myself replied and
>my program was far faster and smaller than the Ansi C,not so Ansi C
>and even the crippled Asm program.
Right, but it was also far less capable. It doesn't run at all on about
two million of the machines in its target audience.
>It was a low dirty "I don't care about OS" program and demonstrated
>the above points #1 and #2.It couldn't be done in C and it was far
>faster and smaller.
Yes, but it also wouldn't work on a large number of the target machines;
Alicia's would have run on many more of them. A C program would have
run on even more.
>My last resort was to rip out his boot rom to make it work,the program
>on the replacement could be the same program! Still running and still
>inexpressible in C! (you should have seen its face when I did this!)
But it *doesn't run*. Not usefully.
>I WON!! and I haven't seen Seebach here anymore although he has the
>nasty habit humilliating me when I help some poor wandering newbie but
>drop on some small philosophical syntaxical item on C which doesn't
>matter anyway (Seebach's with some ... comittee).
Actually, you lost. You demonstrated that you don't understand the
principle of engineering. Your "solution" does not solve; if it were
to solve the problem, it would run on more machines, no? :)
>I can only hope you could grasp why I had to go this low
Because you're trying to prove something unprovable, and you have failed
to notuce your helpful completion of my reductio ad absurdum argument
against it.
>You see:my very first posting to these newsgroups has been a plee for
>peace between C/C++ and Assembly (I myself program in all three of
>them).Reluctantly I have it seen growing to be the third largest
>thread.
The peace we need is for assembly programmers to stop advocating the
addition of assembly to projects that don't need or benefit from it.
-s
--
Copyright 1996 Peter Seebach - seebs at solon.com - C/Unix Wizard
I am not actually dnsa...@earthstar.com but junk mail is accepted there.
The *other* C FAQ, the hacker FAQ, et al. http://www.solon.com/~seebs
Unsolicited email (junk mail and ads) is unwelcome, and will be billed for.
From: Vesa Karvonen <vkar...@paju.oulu.fi>
Subject: Re: Assembly vs c/c++
Date: 1996/12/03
Message-ID: <32A44960.2A22@paju.oulu.fi>#1/1
X-Deja-AN: 202106148
references: <56iv2a$c1p@news.euro.net> <57hfkh$fgd@news.euro.net>
<57uvau$48a@news1.mnsinc.com> <57vvkj$kk1@news.euro.net>
<58187o$ce0@solutions.solon.com>
content-type: text/plain; charset=us-ascii
organization: -
mime-version: 1.0
reply-to: vkar...@raita.oulu.fi
newsgroups: comp.lang.c++,comp.lang.c,comp.lang.asm.x86
x-mailer: Mozilla 3.01Gold (Win95; I)
Peter Seebach wrote:
>
> In article <57vvkj$k...@news.euro.net>,
> Technocrate <usu...@euronet.nl> wrote:
> >2-A good Assembly programmer can make programs which are AT LEAST as
> >fast as a C program.
>
> Only by using compiler output in some cases.
You are not thinking right!
Every algorithm that can be expressed in a compiled HLL can be
expressed in assembly language. You should know this!
You are saying that a compiler could generate code that would
be "in some cases" impossible to derive using only assembly
language. If you can prove this then please do so.
If someone can't better code in assembly language than an
optimizing compiler it doesn't prove that compiler code is
something "unreachable". Kax Kylheky claims that he knows good
assembly language programmers that were "beaten" by a compiler.
That is ridiculous. I wouldn't call those guys _good_ assembly
language programmers. I would call them loosers. The only
conclusion that can be drawn from his assertion is that he
knows a set of really bad programmers.
> >3-Assembly and C/C++ should be used in conjunction for the best
> >performance (that is speed).
>
> Here is where you fall down; you simply haven't got the experience with the
> systems where that simply isn't true.
>
> There are cases where it's simply not possible to usefully improve on
> something through assembly tuning. Adding a variable to a routine in C may
> not only allocate one register differently, but may move something else from
> being an address register to being a data register used as an offset from
> a different address register. You simply can't usefully write your own
> routines which blend with this.
If you constantly need to add/remove variables into/from your
performance critical functions then you are not doing it right!
The basic idea is to consentrate optimzation efforts on the
functions that are both stable and performance critical.
> >You see:my very first posting to these newsgroups has been a plee for
> >peace between C/C++ and Assembly (I myself program in all three of
> >them).Reluctantly I have it seen growing to be the third largest
> >thread.
>
> The peace we need is for assembly programmers to stop advocating the
> addition of assembly to projects that don't need or benefit from it.
How about stopping "hardware ignorant" 'C' programmers from trying to
prove that assembly language programmer can't possibly be smarter than
their optimizing compiler.
==> Vesa Karvonen
From: k...@vision.crest.nt.com (Kaz Kylheku)
Subject: Re: Assembly vs c/c++
Date: 1996/12/03
Message-ID: <5820vp$c5n@bcrkh13.bnr.ca>#1/1
X-Deja-AN: 202152980
references: <56iv2a$c1p@news.euro.net> <57vvkj$kk1@news.euro.net>
<58187o$ce0@solutions.solon.com> <32A44960.2A22@paju.oulu.fi>
organization: Prism Systems Inc.
newsgroups: comp.lang.c++,comp.lang.c,comp.lang.asm.x86
In article <32A449...@paju.oulu.fi>,
Vesa Karvonen <vkar...@raita.oulu.fi> wrote:
>Peter Seebach wrote:
>>
>> In article <57vvkj$k...@news.euro.net>,
>> Technocrate <usu...@euronet.nl> wrote:
>> >2-A good Assembly programmer can make programs which are AT LEAST as
>> >fast as a C program.
>>
>> Only by using compiler output in some cases.
>
>You are not thinking right!
>
>Every algorithm that can be expressed in a compiled HLL can be
>expressed in assembly language. You should know this!
>
>You are saying that a compiler could generate code that would
>be "in some cases" impossible to derive using only assembly
>language. If you can prove this then please do so.
>
>If someone can't better code in assembly language than an
>optimizing compiler it doesn't prove that compiler code is
>something "unreachable". Kax Kylheky claims that he knows good
>assembly language programmers that were "beaten" by a compiler.
>That is ridiculous. I wouldn't call those guys _good_ assembly
>language programmers. I would call them loosers. The only
>conclusion that can be drawn from his assertion is that he
>knows a set of really bad programmers.
You are calling the folk who wrote SPARC routines for PGP and GNU fcrypt
losers. That's fine. All I have to say is this: if you think you are a
hotshot, as opposed to a loser, download the fcrypt code and send me your
improved version of the _SPARC_ assembly language routine. The target platform
will be a Sparcstation 20 (I will supply the test machine and pledge to perform
the test in an impartial manner, the results of which I will post to c.l.c and
c.l.asm.x86).
I suspect that your viewpoint in the assembly language versus HLL debate
is based purely on experience with 80x86. That is about to change if you
decide to try your luck at this. Remember, this is not a test to determine
who is a loser or not. The point of this is education, not humiliation.
>How about stopping "hardware ignorant" 'C' programmers from trying to
>prove that assembly language programmer can't possibly be smarter than
>their optimizing compiler.
How about stopping C standard ignorant assembly programmers, eh? What
do you think of that?
Who was it that didn't know about ANSI C's constraints with respect to floating
point expression evaluation or that sizeof(char) is precisely one? ;)
You know, the phrase "hardware ignorant" _could_ easily be defined to include
programmers who have never written RISC assembly language on a real
workstation, particularly to someone who naively extrapolates PC and
x86-specific knowledge to all computing platforms.
From: af...@james.freenet.hamilton.on.ca (Scott Nudds)
Subject: Re: Assembly vs c/c++
Date: 1996/12/08
Message-ID: <58fc9n$52t@james.freenet.hamilton.on.ca>#1/1
X-Deja-AN: 203037356
references: <56iv2a$c1p@news.euro.net> <57vvkj$kk1@news.euro.net>
organization: Hamilton-Wentworth FreeNet, Ontario, Canada.
newsgroups: comp.lang.c++,comp.lang.c,comp.lang.asm.x86
(Kaz Kylheku) wrote:
: You know, the phrase "hardware ignorant" _could_ easily be defined to include
: programmers who have never written RISC assembly language on a real
: workstation, particularly to someone who naively extrapolates PC and
: x86-specific knowledge to all computing platforms.
Assembly language programmers know there is nothing special about RISC
CPU's, while C programmers consider them entirely mystical.
--
<---->
From: Doug Semler <dse...@uranius.ics.uci.edu>
Subject: Re: Assembly vs c/c++
Date: 1996/12/08
Message-ID: <p9pw0ktj38.fsf@uranius.ics.uci.edu>#1/1
X-Deja-AN: 203086938
references: <56iv2a$c1p@news.euro.net> <57vvkj$kk1@news.euro.net>
organization: UC Irvine, Dept. of Information and Computer Sci
newsgroups: comp.lang.c++,comp.lang.c,comp.lang.asm.x86
> (Kaz Kylheku) wrote: : You know, the phrase "hardware ignorant"
> _could_ easily be defined to include : programmers who have
> never written RISC assembly language on a real : workstation,
> particularly to someone who naively extrapolates PC and :
> x86-specific knowledge to all computing platforms.
Scott Nudds <af...@james.freenet.hamilton.on.ca> writes:
> Assembly language programmers know there is nothing special
> about RISC CPU's, while C programmers consider them entirely
> mystical.
Two words: register windows.
---
Doug Semler | drse...@uci.edu
University of California, Irvine | Garbage In -- Gospel Out
Information and Computer Science | Minister of things to do Next Quarter
http://www.ics.uci.edu/~dsemler | (but will Never Be Done) DNRC O-
A closed mind is a terrible thing | Bus Error (passengers dumped)
From: nat...@hub.ofthe.net
Subject: Re: Assembly vs c/c++
Date: 1996/12/08
Message-ID: <32ABBF61.6017@hub.ofthe.net>#1/1
X-Deja-AN: 203090620
references: <56iv2a$c1p@news.euro.net> <57vvkj$kk1@news.euro.net>
content-type: text/plain; charset=us-ascii
mime-version: 1.0
reply-to: nat...@hub.ofthe.net
newsgroups: comp.lang.c++,comp.lang.c,comp.lang.asm.x86
x-mailer: Mozilla 3.0Gold (Win16; I)
Doug Semler wrote:
>
> > (Kaz Kylheku) wrote: : You know, the phrase "hardware ignorant"
> > _could_ easily be defined to include : programmers who have
> > never written RISC assembly language on a real : workstation,
> > particularly to someone who naively extrapolates PC and :
> > x86-specific knowledge to all computing platforms.
>
> Scott Nudds <af...@james.freenet.hamilton.on.ca> writes:
> > Assembly language programmers know there is nothing special
> > about RISC CPU's, while C programmers consider them entirely
> > mystical.
> Two words: register windows.
Ok, I'll bite tonite, let me guess first though.
You are asking SN to register Windows 95? probably not
Then let's assume you are talking about data registers.
Then let's assume multiple register sets.
Like the TI 9900? which had external register sets.
Or switchable internal register sets.
I ran out of guesses, clue me.
I have worked on at least 50 different processor designs, including main
frame and RISC but this is not ringing a bell.
So these are my two words: I give.
> ---
> Doug Semler | drse...@uci.edu
> University of California, Irvine | Garbage In -- Gospel Out
> Information and Computer Science | Minister of things to do Next Quarter
> http://www.ics.uci.edu/~dsemler | (but will Never Be Done) DNRC O-
> A closed mind is a terrible thing | Bus Error (passengers dumped)
I like the tag line.
--
mailto:nat...@hub.ofthe.net
http://www.geocities.com/WallStreet/6173
From: Doug Semler <dse...@uranius.ics.uci.edu>
Subject: Re: Assembly vs c/c++
Date: 1996/12/09
Message-ID: <p99178klip.fsf@uranius.ics.uci.edu>#1/1
X-Deja-AN: 203122726
references: <56iv2a$c1p@news.euro.net> <57vvkj$kk1@news.euro.net>
organization: UC Irvine, Dept. of Information and Computer Sci
newsgroups: comp.lang.c++,comp.lang.c,comp.lang.asm.x86
natasha <nat...@hub.ofthe.net> writes:
> Doug Semler wrote:
>>> (Kaz Kylheku) wrote:
>>>> You know, the phrase "hardware ignorant" _could_ easily be
>>>> defined to include programmers who have never written RISC
>>>> assembly language on a real workstation, particularly to
>>>> someone who naively extrapolates PC and x86-specific knowledge
>>>> to all computing platforms.
>>
>> Scott Nudds <af...@james.freenet.hamilton.on.ca> writes:
>>> Assembly language programmers know there is nothing special
>>> about RISC CPU's, while C programmers consider them entirely
>>> mystical.
>> Two words: register windows.
> Ok, I'll bite tonite, let me guess first though. You are
> asking SN to register Windows 95? probably not
:) No, we all know that SN is a DOS programmer...
(could you imagine programming assembly and trying to interface MFC
Windows funcs??!)
> Then let's assume you are talking about data registers. Then
> let's assume multiple register sets. Like the TI 9900? which
> had external register sets. Or switchable internal register
> sets. I ran out of guesses, clue me. I have worked on at
> least 50 different processor designs, including main frame and
> RISC but this is not ringing a bell.
I'm talking Sparc like register window, where you have
o0-7, g0-7, and i0-7, and then when you do a call, the o0-7
becomes the i0-7 of the called procedure. You know, a register window :)
Totally non existant on the x86 architecture.
Another thing SN has to take into consideration when he writes his
pasm is the Sparc's branch delay. Again, non-existant
on the x86 (well, the 386/486 set, at least, it's been a while since
I've looked at the 586 instruction set).
Oh, yeah, don't forget, VLIW machine instructions for pasm....
How are you going to optimize those, Scott? Remember, if you want to
have it portable, you can't support multiple ops per instruction, therby
losing the whole purpose of having the VLIW in the first place.
(And don't try to contradict me here, this is my research area.)
Hell, register allocation after optimizing for VLIW is an NP-complete
problem!
Oh, btw, Scott, C doesn't optimize for shit. The compilers available on
the PC market optimize the generated IR code for shit; probably because
of the fact that they are trying to compromise for all variations of the
x86 architecture. I'd like to see you write a generalized optimizer
for the 386, 486, and pentium instruction sets, then also do it for Sparc,
HP, oh, and whatever other sets you can think of.
> So these are my two words: I give.
>> ---
>> Doug Semler | drse...@uci.edu
>> University of California, Irvine | Garbage In -- Gospel Out
>> Information and Computer Science | Minister of things to do Next Quarter
>> http://www.ics.uci.edu/~dsemler | (but will Never Be Done) DNRC O-
>> A closed mind is a terrible thing | Bus Error (passengers dumped)
> I like the tag line.
thanks :)
---
Doug Semler | drse...@uci.edu
University of California, Irvine | Garbage In -- Gospel Out
Information and Computer Science | Minister of things to do Next Quarter
http://www.ics.uci.edu/~dsemler | (but will Never Be Done) DNRC O-
A closed mind is a terrible thing | Bus Error (passengers dumped)
From: af...@james.freenet.hamilton.on.ca (Scott Nudds)
Subject: Re: Assembly vs c/c++
Date: 1996/12/16
Message-ID: <593efq$fvp@james.freenet.hamilton.on.ca>#1/1
X-Deja-AN: 204375147
references: <56iv2a$c1p@news.euro.net>
organization: Hamilton-Wentworth FreeNet, Ontario, Canada.
newsgroups: comp.lang.c++,comp.lang.c,comp.lang.asm.x86
Doug Semler wrote:
: Another thing SN has to take into consideration when he writes his
: pasm is the Sparc's branch delay.
What problem do you have with delayed branches?
Doug Semler wrote:
: Oh, yeah, don't forget, VLIW machine instructions for pasm....
: How are you going to optimize those, Scott?
You seem to find a lot of non-existent problems.
Doug Semler wrote:
: Remember, if you want to
: have it portable, you can't support multiple ops per instruction, therby
: losing the whole purpose of having the VLIW in the first place.
You can support anything you like. Perhaps you should described what
you <think> the problem is here.
Doug Semler wrote:
: Oh, btw, Scott, C doesn't optimize for shit.
Apparently you can't distinguish between optimized assembler and C.
C optimizes like shit.
--
<---->
From: Doug Semler <dse...@octavian.ics.uci.edu>
Subject: Re: Assembly vs c/c++
Date: 1996/12/16
Message-ID: <p9ybeyo2ek.fsf@octavian.ics.uci.edu>#1/1
X-Deja-AN: 204402051
references: <56iv2a$c1p@news.euro.net>
organization: UC Irvine, Dept. of Information and Computer Sci
newsgroups: comp.lang.c++,comp.lang.c,comp.lang.asm.x86
Scott Nudds <af...@james.freenet.hamilton.on.ca> writes:
> Doug Semler wrote:
> : Another thing SN has to take into
> consideration when he writes his : pasm is the Sparc's branch
> delay.
> What problem do you have with delayed branches?
*I* have no problems. Apparantly you have a problem with reading
comprehension...How the F*&# will a "portable" assembler handle
the difference between a branch delay on a SPARC and a lack of
branch delay on an x86!?
> Doug Semler wrote: : Oh, yeah, don't forget, VLIW machine
> instructions for pasm.... : How are you going to optimize
> those, Scott?
> You seem to find a lot of non-existent problems.
Oh, yeah, since this pasm is non-exsistent. Answer the flipping question:
HOW ARE YOU GOING TO OPTIMIZE FOR VLIW IN A PORTABLE ASSEMBLER.
Hint: By definition, it will be impossible.
> Doug Semler wrote: : Remember, if you want to : have it
> portable, you can't support multiple ops per instruction,
> therby : losing the whole purpose of having the VLIW in the
> first place.
> You can support anything you like. Perhaps you should
> described what you <think> the problem is here.
Duh, I *DID*, idiot. A portable assembler will not support
multi-op instructions on a 80486. Thereby, it is no longer portable.
> Doug Semler wrote: : Oh, btw, Scott, C doesn't optimize for
> shit.
> Apparently you can't distinguish between optimized assembler
> and C. C optimizes like shit.
I see you suffer from selective quoting. Your portable assembler
will suffer the EXACT same optimization problems that C compilers do.
Now get your head out of your ass, dumbf*(k
---
Doug Semler | drse...@uci.edu
University of California, Irvine | Garbage In -- Gospel Out
Information and Computer Science | Minister of things to do Next Quarter
http://www.ics.uci.edu/~dsemler | (but will Never Be Done) DNRC O-
A closed mind is a terrible thing | Bus Error (passengers dumped)
"If Unix isn't inferior to Windows, then why does the marketplace
consistently chose Windows over Unix? Are you a socialist who believes
the marketplace does not make the most optimal choices?" -- Scott Nudds
From: af...@james.freenet.hamilton.on.ca (Scott Nudds)
Subject: Re: Assembly vs c/c++
Date: 1996/12/26
Message-ID: <59uno2$oo4@james.freenet.hamilton.on.ca>#1/1
X-Deja-AN: 206087509
references: <56iv2a$c1p@news.euro.net>
<593efq$fvp@james.freenet.hamilton.on.ca>
organization: Hamilton-Wentworth FreeNet, Ontario, Canada.
newsgroups: comp.lang.c++,comp.lang.c,comp.lang.asm.x86
Doug Semler wrote:
: *I* have no problems. Apparantly you have a problem with reading
: comprehension...How the F*&# will a "portable" assembler handle
: the difference between a branch delay on a SPARC and a lack of
: branch delay on an x86!?
Weeks ago it was made very clear that the assembler is free to choose
absolute register assignments and instruction sequence.
Doug Semler wrote:
: Answer the flipping question:
: HOW ARE YOU GOING TO OPTIMIZE FOR VLIW IN A PORTABLE ASSEMBLER.
VLIW's would be handled no differently (conceptually) than any other
instruction type. What problem do you think you see?
Doug Semler wrote:
: Hint: By definition, it will be impossible.
Foolish. Why do you think it is impossible?
Doug Semler wrote:
: Duh, I *DID*, idiot. A portable assembler will not support
: multi-op instructions on a 80486. Thereby, it is no longer portable.
Sets of concurrent operations can built from a standard linear stream
of written instructions. Why do you think otherwise? Do you really
think that you can't run Fortran on such a machine?
Doug Semler wrote:
: I see you suffer from selective quoting. Your portable assembler
: will suffer the EXACT same optimization problems that C compilers do.
You can not specify the frequency of variable use in C, you can not
perform direct register manipulation, you can not manipulate the stack
or flags register, you can not return data in the flags, register, or
perform rolls pushes or pops. These functions are required for writing
efficient code.
C does not give you the ability, hence it optimizes like shit.
--
<---->
From: Richard Krehbiel <ri...@kastle.com>
Subject: Re: Assembly vs c/c++
Date: 1996/12/27
Message-ID: <urakccipu.fsf@kastle.com>#1/1
X-Deja-AN: 206196304
references: <56iv2a$c1p@news.euro.net>
organization: Kastle Systems
newsgroups: comp.lang.c++,comp.lang.c,comp.lang.asm.x86
af...@james.freenet.hamilton.on.ca (Scott Nudds) writes:
> Doug Semler wrote:
> : I see you suffer from selective quoting. Your portable assembler
> : will suffer the EXACT same optimization problems that C compilers do.
>
> You can not specify the frequency of variable use in C, you can not
> perform direct register manipulation,
If you do so in "pasm" it won't be portable.
> you can not manipulate the stack
> or flags register,
If you do so in "pasm" it will not be portable.
> you can not return data in the flags register,
If you do so in "pasm" it will not be portable.
> or perform rolls pushes or pops.
If you do so in "pasm" it will not be portable.
> These functions are required for writing
> efficient code.
>
> C does not give you the ability, hence it optimizes like shit.
Hey, Scott, I've got your pasm right here. It's perfect for the roll-
your-own take-full-responsibility assembly hacker. It's m4|gas.
Here's how it works: m4 is a mucho-powerful macro processor, and gas
is an assembler from FSF that has fairly consistent syntax and can be
built for several popular platforms. With this combination, you can
now write source that can be ported to any platform you choose that
gas supports. And the best part is, you have full control of the
generated code! You can use machine specific registers and condition
codes and delayed branches, if you have them. Register windows, or
the lack thereof, are no problem. All you have to do is surround the
perfectly optimized code for each platform by macro directives that
select the target CPU type. The program's as portable as you wish!
Code for the targets you need, and forget the rest. Since all the
targets' source is consolidated into a single file, maintenance will
be a breeze! You (yes you!) can build m4 macros to simplify the
source code (heh - as if it would need simplifying), and whatever
optimization they do to generate common instruction sequences, it
*couldn't* be shit because it's all under your control! Think of the
awesome power! Since there's no pesky standard libraries with stupid
function names, everything will have the name you give is, just as God
gave Adam to name all the animals of the earth!
Your programming power will increase, yea, to seventy times seven!
The unwashed C philistines will see their error and fall to your feet
in worship! (After all, isn't that what you *really* want?)
--
Richard Krehbiel, Kastle Systems, Arlington, VA, USA
ri...@kastle.com (work) or ri...@mnsinc.com (personal)
From: "Dennis Weldy" <dmw...@ingr.com>
Subject: Re: Assembly vs c/c++
Date: 1996/12/28
Message-ID: <01bbf4e1$21dfbab0$12938781@weldypc>#1/1
X-Deja-AN: 206426801
references: <56iv2a$c1p@news.euro.net>
<593efq$fvp@james.freenet.hamilton.on.ca>
<59uno2$oo4@james.freenet.hamilton.on.ca> <urakccipu.fsf@kastle.com>
organization: Intergraph
newsgroups: comp.lang.c++,comp.lang.c,comp.lang.asm.x86
Howdy,
Richard Krehbiel <ri...@kastle.com> wrote in article
<urakcc...@kastle.com>...
> af...@james.freenet.hamilton.on.ca (Scott Nudds) writes:
>
> > You can not specify the frequency of variable use in C, you can not
> > perform direct register manipulation,
>
> If you do so in "pasm" it won't be portable.
Well, what COULD be done is to give the registers "abstract" names, such as
r0, r1, r2, .... rn, n >= 0
registers which the program uses which are not implemented on the target
would be "spilled" into memory. The target cpu has m registers m < n, m >=
0. I would assume that the programmer would put the most-frequently used
variables into registers r0 onwards since these would likely be hardware
registers.
Of course, some architectures may allow you to combine two adjacent 32-bit
registers into one 64-bit register for purposes of shifting, rotation, etc.
This would either
a) be supported on all implementations of pasm, emulated on those
architectures that dont support it
b) the user has a way to embed naitive machine code.
Another instance - consider the LOOP instructions of the 80x86. Modifies a
register CX then branches to the given label if non-zero. If implemented
directly in pasm, which register do we assign to cx? Note that to be
portable (if indeed its decided that this instruction is to be implemented
as a "portable" instruction) this register assignment would have to be
permanent, and emulated on thse architectures that don't have a LOOP
instruction. If it's decided that this is not to be portable... then
someone will complain about efficiency :-).
OK, you could include the following construct
do(counter = 12) {
// pasm instructions
} while(--counter != 0) ;
Pasm could look for this construct & generate the appropriate code. Is this
type of construct appropriate for a 68000? Sparc? HP-Risc? IBM 360? I dont
know. It should translate on the 80x86 to
mov cx, 12
label067:
.....
loop label067
Nicely efficient. Note that other architectures may have more efficient
constructs. Also note that I designed the above construct with the 80x86
LOOP in mind. Would one have to look at every instruction for every common
architecture to decide what's portable and what isn't? That could take a
while :-).
Another example - the REP instruction. Again it uses the CX register. It
probably could be handled by the above structure if theres a single pasm
instruction of the appropriate type. Otherwise it generates standard loop
code.
My point is, that it would be possible to come up with portable pasm-type
constructs for the particular architecture, these may not be the most
efficient on other architectures. If made generic enough, they would come
to resemble:
counter = 12 ;
do {
// pasm instructions
} while(--counter != 0) ;
Golly, that look familiar to anyone? :-).
// its either C, C++, or Java. Sould work in all three languages.
>
> > you can not manipulate the stack
> > or flags register,
>
> If you do so in "pasm" it will not be portable.
Cmon now, whatever's not supported naitively will be emulated. :-)
>
> > you can not return data in the flags register,
>
> If you do so in "pasm" it will not be portable.
See above. Of course, on some architectures that don't have a flags
register (I believe someone here has stated this is the case) this wont be
done efficiencly but I guess efficiency can be sacrificed in the name of
portability.
>
> > or perform rolls pushes or pops.
See above. rolls, pushes and pops would be emulated.
>
> If you do so in "pasm" it will not be portable.
>
> > These functions are required for writing
> > efficient code.
> >
> > C does not give you the ability, hence it optimizes like shit.
>
> Hey, Scott, I've got your pasm right here. It's perfect for the roll-
> your-own take-full-responsibility assembly hacker. It's m4|gas.
>
Note:
From: d...@cwi.nl (Dik T. Winter)
Subject: Re: Assembly vs c/c++
Date: 1996/12/29
Message-ID: <E35K95.Avs@cwi.nl>#1/1
X-Deja-AN: 206502793
sender: ne...@cwi.nl (The Daily Dross)
references: <59uno2$oo4@james.freenet.hamilton.on.ca> <urakccipu.fsf@kastle.com>
<01bbf4e1$21dfbab0$12938781@weldypc>
organization: CWI, Amsterdam
newsgroups: comp.lang.c++,comp.lang.c,comp.lang.asm.x86
In article <01bbf4e1$21dfbab0$12938781@weldypc> "Dennis Weldy" <dmw...@ingr.com>
writes:
> > > You can not specify the frequency of variable use in C, you can not
> > > perform direct register manipulation,
> >
> > If you do so in "pasm" it won't be portable.
>
> Well, what COULD be done is to give the registers "abstract" names, such as
> r0, r1, r2, .... rn, n >= 0
Ok, pray tell me how to map that on the Cray. It has the following
registers:
S0 - S7, 64-bit arithmetic registers
A0 - A7, 32-bit (address) arithmetic registers
B0 - B63, 64-bit registers, but communicate only with S0 - S7 and memory
T0 - T63, 32-bit registers, but communicate only with A0 - A7 and memory
V0 - V7, 64 (or 128 on newer models) x 64-bit vector registers.
VL, 6 or 7-bit vector length register.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
From: Ben Sauvin <sau...@csql.mv.com>
Subject: Re: Assembly vs c/c++
Date: 1996/12/29
Message-ID: <32C5D9B4.4216@csql.mv.com>#1/1
X-Deja-AN: 206513007
x-nntp-posting-host: lnh-1-02.mv.com
references: <59uno2$oo4@james.freenet.hamilton.on.ca> <urakccipu.fsf@kastle.com>
<01bbf4e1$21dfbab0$12938781@weldypc> <E35K95.Avs@cwi.nl>
content-type: text/plain; charset=us-ascii
organization: CSQL TechServe
mime-version: 1.0
reply-to: sau...@csql.mv.com
newsgroups: comp.lang.c++,comp.lang.c,comp.lang.asm.x86
x-mailer: Mozilla 3.0 (Win95; I)
Dik T. Winter wrote:
>
> In article <01bbf4e1$21dfbab0$12938781@weldypc> "Dennis Weldy" <dmw...@ingr.com>
> writes:
> > > > You can not specify the frequency of variable use in C, you can not
> > > > perform direct register manipulation,
> > >
> > > If you do so in "pasm" it won't be portable.
> >
> > Well, what COULD be done is to give the registers "abstract" names, such as
> > r0, r1, r2, .... rn, n >= 0
>
> Ok, pray tell me how to map that on the Cray. It has the following
> registers:
> S0 - S7, 64-bit arithmetic registers
> A0 - A7, 32-bit (address) arithmetic registers
> B0 - B63, 64-bit registers, but communicate only with S0 - S7 and memory
> T0 - T63, 32-bit registers, but communicate only with A0 - A7 and memory
> V0 - V7, 64 (or 128 on newer models) x 64-bit vector registers.
> VL, 6 or 7-bit vector length register.
> --
> dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
> home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
And, what the hell, I'll show just a bit of ignorance and ask just how
the hell this "register spillover into memory" would help
register-starved machines based on (for example) the 6502? How does the
"portable assembly" decide on "optimal register use" when there
virtually ARE no registers?
I ask that because microcontrollers based on exactly such
microprocesors are far from dead, yet (or do things like burglar alarms,
microwave ovens and computerised stethoscopy not count as "real-world
programming"?).
--
Benoit A Sauvin
Anti-junk/spam device: underscore.
Opinions and misstatements are my own.
From: af...@james.freenet.hamilton.on.ca (Scott Nudds)
Subject: Re: Assembly vs c/c++
Date: 1997/01/07
Message-ID: <5atnsn$n71@james.freenet.hamilton.on.ca>#1/1
X-Deja-AN: 208296442
references: <59uno2$oo4@james.freenet.hamilton.on.ca>
organization: Hamilton-Wentworth FreeNet, Ontario, Canada.
newsgroups: comp.lang.c++,comp.lang.c,comp.lang.asm.x86
Ben Sauvin <sau...@csql.mv.com> wrote:
: And, what the hell, I'll show just a bit of ignorance and ask just how
: the hell this "register spillover into memory" would help
: register-starved machines based on (for example) the 6502? How does the
: "portable assembly" decide on "optimal register use" when there
: virtually ARE no registers?
Clearly by attempting to keep the most frequently used variables in
registers, the same thing it does for every other CPU. The fact that
the CPU has 4 registers or 400, makes no difference what so ever.
What does Ben Sauvin think HLL's do when implemented on the 6502?
Portable assembler would however allow the programmer direct control
over register allocation where possible.
Having said this I recognize the fact that to date no C pusher has
managed to find a C compiler for any 8 bit CPU.
--
<---->
From: jjbi...@atlantis.actrix.gen.nz (John Bickers)
Subject: Re: Assembly vs c/c++
Date: 1997/01/09
Message-ID: <5b3jva$1hi@asgard.actrix.gen.nz>#1/1
X-Deja-AN: 208990499
references: <59uno2$oo4@james.freenet.hamilton.on.ca>
<5atnsn$n71@james.freenet.hamilton.on.ca>
organization: Actrix Networks Limited
newsgroups: comp.lang.c++,comp.lang.c,comp.lang.asm.x86
In article <5atnsn$n...@james.freenet.hamilton.on.ca>,
Scott Nudds <af...@james.freenet.hamilton.on.ca> wrote:
> Having said this I recognize the fact that to date no C pusher has
> managed to find a C compiler for any 8 bit CPU.
One of the companies that published programming books for the
C=64, maybe Abacus, also had a C compiler for it.
There are also cross-compilers that run on larger computers but
generate code for smaller ones, although not being interested in
such things I don't know any specific products.
From: "David V. Mills" <d...@onaustralia.com.au>
Subject: Re: Assembly vs c/c++
Date: 1997/01/16
Message-ID: <01bc038b$c0b5ab00$1f150dcb@meerkat.onaustralia.com.au>#1/1
X-Deja-AN: 210368297
references: <59uno2$oo4@james.freenet.hamilton.on.ca>
<5atnsn$n71@james.freenet.hamilton.on.ca> <5b3jva$1hi@asgard.actrix.gen.nz>
organization: On Australia
newsgroups: comp.lang.c
John Bickers <jjbi...@atlantis.actrix.gen.nz> wrote in article
<5b3jva$1...@asgard.actrix.gen.nz>...
> In article <5atnsn$n...@james.freenet.hamilton.on.ca>,
> Scott Nudds <af...@james.freenet.hamilton.on.ca> wrote:
>
> > Having said this I recognize the fact that to date no C pusher has
> > managed to find a C compiler for any 8 bit CPU.
>
> One of the companies that published programming books for the
> C=64, maybe Abacus, also had a C compiler for it.
>
Yep, there were at least three C compilers for the C-64... Also Small C
was written on (and for) the 8085...
As well as that, Hi-Tech make a bunch of C compilers for just about any
embedded chip you can think of... of course, the compilers for things like
the 1802 run as cross-compilers, but one of the 8085/Z-80/HD64180 ones does
run under CP/M...
Cheers,
David.
--
David V. Mills d...@onaustralia.com.au
From: fr...@genesis.demon.co.uk (Lawrence Kirby)
Subject: Re: Assembly vs c/c++
Date: 1997/01/17
Message-ID: <853512987snz@genesis.demon.co.uk>#1/1
X-Deja-AN: 210531684
references: <59uno2$oo4@james.freenet.hamilton.on.ca>
<5atnsn$n71@james.freenet.hamilton.on.ca>
<5b3jva$1hi@asgard.actrix.gen.nz>
<01bc038b$c0b5ab00$1f150dcb@meerkat.onaustralia.com.au>
x-mail2news-user: fr...@genesis.demon.co.uk
x-mail2news-path: genesis.demon.co.uk
organization: none
reply-to: fr...@genesis.demon.co.uk
newsgroups: comp.lang.c
In article <01bc038b$c0b5ab00$1f15...@meerkat.onaustralia.com.au>
d...@onaustralia.com.au "David V. Mills" writes:
>John Bickers <jjbi...@atlantis.actrix.gen.nz> wrote in article
><5b3jva$1...@asgard.actrix.gen.nz>...
>> In article <5atnsn$n...@james.freenet.hamilton.on.ca>,
>> Scott Nudds <af...@james.freenet.hamilton.on.ca> wrote:
>>
>> > Having said this I recognize the fact that to date no C pusher has
>> > managed to find a C compiler for any 8 bit CPU.
>>
>> One of the companies that published programming books for the
>> C=64, maybe Abacus, also had a C compiler for it.
>>
> Yep, there were at least three C compilers for the C-64...
>Also Small C>was written on (and for) the 8085...
>
> As well as that, Hi-Tech make a bunch of C compilers for just about any
>embedded chip you can think of... of course, the compilers for things like
>the 1802 run as cross-compilers, but one of the 8085/Z-80/HD64180 ones does
>run under CP/M...
Calling something a C compiler implies that it conforms to the requirements
of the C language. In practice you have to allow a little latitude for
compiler bugs (as long as they can be considered bugs) but the compiler should
still be close. DO any of the compilers listed meet these requirements?
Cross-compilers are fine.
--
-----------------------------------------
Lawrence Kirby | fr...@genesis.demon.co.uk
Wilts, England | 7073...@compuserve.com
-----------------------------------------
From: jjbi...@atlantis.actrix.gen.nz (John Bickers)
Subject: Re: Assembly vs c/c++
Date: 1997/01/21
Message-ID: <5c17g3$j31@asgard.actrix.gen.nz>#1/1
X-Deja-AN: 211180358
references: <59uno2$oo4@james.freenet.hamilton.on.ca>
<5b3jva$1hi@asgard.actrix.gen.nz>
<01bc038b$c0b5ab00$1f150dcb@meerkat.onaustralia.com.au>
<853512987snz@genesis.demon.co.uk>
organization: Actrix Networks Limited
newsgroups: comp.lang.c
In article <853512...@genesis.demon.co.uk>,
Lawrence Kirby <fr...@genesis.demon.co.uk> wrote:
> Calling something a C compiler implies that it conforms to the requirements
> of the C language. In practice you have to allow a little latitude for
Can we insert " at the time" after the word "language"? If not,
then the first C compiler wouldn't be K&R's! This is as bizarre
as not being able to write the standard libraries in standard C.
From: fr...@genesis.demon.co.uk (Lawrence Kirby)
Subject: Re: Assembly vs c/c++
Date: 1997/01/21
Message-ID: <853854170snz@genesis.demon.co.uk>#1/1
X-Deja-AN: 211382244
references: <59uno2$oo4@james.freenet.hamilton.on.ca>
<5b3jva$1hi@asgard.actrix.gen.nz>
<01bc038b$c0b5ab00$1f150dcb@meerkat.onaustralia.com.au>
<853512987snz@genesis.demon.co.uk> <5c17g3$j31@asgard.actrix.gen.nz>
x-mail2news-user: fr...@genesis.demon.co.uk
x-mail2news-path: genesis.demon.co.uk
organization: none
reply-to: fr...@genesis.demon.co.uk
newsgroups: comp.lang.c
In article <5c17g3$j...@asgard.actrix.gen.nz>
jjbi...@atlantis.actrix.gen.nz "John Bickers" writes:
>In article <853512...@genesis.demon.co.uk>,
>Lawrence Kirby <fr...@genesis.demon.co.uk> wrote:
>
>> Calling something a C compiler implies that it conforms to the requirements
>> of the C language. In practice you have to allow a little latitude for
>
> Can we insert " at the time" after the word "language"?
The usual implication is the current requirements of the language.
> If not,
> then the first C compiler wouldn't be K&R's!
Certainly the first C compiler is not a C compiler by today's standards,
calling it a C compiler in 1997 *without suitable qualification* would be
misleading and incorrect.
>This is as bizarre
> as not being able to write the standard libraries in standard C.
Why is that bizarre - the standard library functions can't in general be
written in C (at least not if they do anythi9ng useful). How would you
write time() in C such that it returned actual time values rather than
just say:
#include <time.h>
time_t time(time_t *timer)
{
return (time_t)-1;
}
The reason that many standard library functions exist is to provide
functionality that doesn't otherwise exist in the language.
--
-----------------------------------------
Lawrence Kirby | fr...@genesis.demon.co.uk
Wilts, England | 7073...@compuserve.com
-----------------------------------------
From: jjbi...@atlantis.actrix.gen.nz (John Bickers)
Subject: Re: Assembly vs c/c++
Date: 1997/01/23
Message-ID: <5c8flu$mjd@asgard.actrix.gen.nz>#1/1
X-Deja-AN: 211827827
references: <59uno2$oo4@james.freenet.hamilton.on.ca>
<853512987snz@genesis.demon.co.uk> <5c17g3$j31@asgard.actrix.gen.nz>
<853854170snz@genesis.demon.co.uk>
organization: Actrix Networks Limited
newsgroups: comp.lang.c
In article <853854...@genesis.demon.co.uk>,
Lawrence Kirby <fr...@genesis.demon.co.uk> wrote:
> >This is as bizarre
> > as not being able to write the standard libraries in standard C.
>
> Why is that bizarre - the standard library functions can't in general be
> written in C (at least not if they do anythi9ng useful). How would you
Exactly. This has taken C to another level, sort of like how C++
has done so except not so intensely. I remember the days when
Pascal used to be derided because the language couldn't be
written in Pascal itself.
It just goes to show that in many real life applications, C, as
in Standard C, is next to useless. It's a matter of perception,
and fortunately many programmers aren't aware of or don't care
about this view.
From: Andrew Veliath <vel...@rpi.edu>
Subject: Re: Assembly vs c/c++
Date: 1997/01/24
Message-ID: <m3u3o7c7f5.fsf@pluto.solarsystem.org>#1/1
X-Deja-AN: 212107337
sender: vel...@pluto.solarsystem.org
references: <59uno2$oo4@james.freenet.hamilton.on.ca>
content-type: text/plain; charset=US-ASCII
organization: Rensselaer Polytechnic Institute, The United States of America
mime-version: 1.0 (generated by tm-edit 7.92)
newsgroups: comp.lang.c
>>>>> Homer Simpson, with all his power, protested:
>>>>> "All perform aerial maneuvers at the words of the omnipresent
>>>>> John Bickers!"
>> >This is as bizarre > as not being able to write the standard
>> libraries in standard C.
>>
>> Why is that bizarre - the standard library functions can't in
>> general be written in C (at least not if they do anythi9ng
>> useful). How would you
John> Exactly. This has taken C to another level, sort of like
John> how C++ has done so except not so intensely. I remember the
John> days when Pascal used to be derided because the language
John> couldn't be written in Pascal itself.
John> It just goes to show that in many real life
John> applications, C, as in Standard C, is next to useless. It's
John> a matter of perception, and fortunately many programmers
John> aren't aware of or don't care about this view.
Actually, knowledge of Standard C can be quite useful. Knowing the
standard is less important than having a good working knowledge (and
experience with) of the standard's limitations. I could go to NetLib,
for example, and obtain lots of free C code which will compile right
on the SGI/IBM/Linux/Sun/embedded processer, etc.
Given the right understanding of the problem domain, course of
approach, and level of experience (as well as lack of zeal!),
development can be speeded up significantly by fair use of whatever
tools you have available.
I find this entire argument of Assembly vs. C/C++/HLL (coming on
pay-per-view next week!! :-) absurd. Any competent programmer with
some experience should have an idea of where and how to interface
anything required to get the job done faster, cheaper, or more
elegantly (take your pick; although "experience" is the keyword
here...).
I've found it most effective on embedded systems to write the
algorithms in C (ANSI), interfaced to a pretty simple low-level driver
model (written in both C and target asm, whichever suits to task) so I
can run my embedded software or library under a Unix machine as well
as the target embedded processor. I've found debugging the algorithms
to be faster this way, since I can use all of the glitzy debuggers
under Unix. Even if the algorithm implementation will be redone in
asm later for speed, writing first in a higher language can be faster
and easier to change during development (this really can't be
understated).
It seems to me that this is an argument for the sake of a language or
methodology without a purpose; which doesn't appear to be very
productive in itself.
Regards,
Andrew
--
Andrew Veliath <vel...@rpi.edu> http://www.rpi.edu/~veliaa
One day, all forms of communication will be superseded by a FAQ.
Finger for PGP Public Key
Key fingerprint = 51 56 5D 3E 51 43 8B 74 7C B2 E4 B6 84 8E 8B 08