structured assembler
Mike Schwartz
I wrote for a real nice structured programming language for the 6502.
First, however, a little background.
I am a video game programmer with several years experience. I also was
probably the 2nd person to use the Lattice 'C' compiler almost 10 years
ago (it wasn't for the 8086/88 family yet), so I have a bit of 'C'
programming experience. I have noticed a real absurd notion among some
people that video game programmers are not "real" engineers, but I think
they are the cream of the crop.
In the last 3 years, I have written over 300K of 6502 code alone, not
even including 6809, Z80, 8086, and 68000 code I had to write. On each
of these machines (ColecoVision, IBM PC, Commodore 64, Atari 800, Atari
VCS, etc.), a good program had to squeeze every cpu cycle, byte of RAM,
and byte of ROM out of every program. Some of the machines were quite
crude; the VCS had 128 bytes of RAM and 4K of ROM; the ColecoVision had
maybe 4K of RAM and 16K of ROM, etc. Some of the machines were actually
reasonable computers (C64, Atari 800) with lots of Ram and disk drives.
I think 'C' is a very good language for the average engineer (most of us
are average by definition), but is unusable for any application where
speed and code size are real critical. I admit you can hand optimize,
etc., 'C' programs to make them better, but such a program could never
be as fast or as small as a well written Assembler language program.
'C' has its advantages, though, which every video game programmer would
like to take advantage of (speed of development, portability, etc.).
This brings me to BASM. BASM is a compiler/assembler I bought for the
C64, when I was looking for development tools. BASM was advertised as
a Basic Compiler, and the source strongly resembled BASIC. However,
upon careful examination, I found that what BASM really is is a RATFOR
for 6502 assembler language (instead of fortran). The idea intrigued
me, and I ended up using it for quite a bit of development. The
biggest drawback of the language was that it was native to the C64, and
therefore horribly slow (100 Baud serial disk drives, echhh).
What does a RATFOR for 6502 assembler language look like? Well, let's
look at an example:
-------------------
putchar=$ffd2 ; C64 Rom kernel put char to screen routine
main
for i = 1 to 100
puthex i
next i
stop ; return to shell
def puthex h
lsr a : lsr a : lsr a : lsr a : tax
putchar hextab,x
let h and $0f : tax
putchar hextab,x
return
enddef puthex
hextab data "0123456789abcdef"
end
The above example will print the numbers 1 to 100 in hex. If you can
read 6502 code (after all, it is the simplest of all major micros), you
will recognize some assembler language syntax (lsr a tax etc.).
BASM lets you mix high level constructs (while, for, if then else, etc.)
with assembler language to form a very elegent ('C' eat your heart out)
compact program. BASM seems to have all of the major advantages of 'C',
yet it generates code nearly as well as anyone can by hand.
This leads me to some questions that I have for all the UNIX gurus out
there. Is 'C' really portable, or is UNIX pretty tough to port anyway
(by pretty tough, I mean a few months' work)? Are other applications
written in 'C' really portable? (I bet most are near impossible to
port from UNIX to the 8086). Is it worth it for portability to have
programs that run at half the speed (or less) than the computer is
capable of (or will it matter if they make computers go fast enough)?
Or does it make more sense to use a language that fits the architecture
of the target machine (faster smaller code)? Is time better spent porting
code that is not optimized for the target (but works) or is that time better
spent making a more optimized program for the target? Does anyone else
besides me notice that the IBM PC AT runs rings around UNIX in any
environment I have seen it (PDP-11 and VAXes) - MS DOS is written in
assembler language? Does anyone care how big their programs are?
Does anyone care how big the runtime libraries are (BASM has no
runtime library period)?
Should it matter that a language called Action (similar to BASM) on a
toy Atari 800 can compile a megabyte of source code (a little overstated)
in the time any 'C' compiler I have seen can compile "Hello, World"?
Is portability a reality? I can port a BASM program from the C64 to
the C128 to the Atari 800 to the Apple II faster than a 'C' program can
be ported from Unix to the IBM PC, and we are talking about 20 MILLION
machines. Will a 'C' program ever be ported from the Amiga or ST to
anywhere else (the Amiga OS has maybe 400 functions not supported by
Unix)? How many are worth porting the other way?
I have not been trying to flame 'C', which is a Ratfor for PDP-11 assembler
language, so please nobody take this as a personal attack against some
hallowed institution. What I have been trying to do is provide some
food for thought for those of you out there who want to write compilers.
The world needs more Modula and Pascal and 'C' compilers like we all
need another hole in the head. How about using 'C' to bootstrap a
new language that fits a machine's architecture reasonably.
I shudder to think of a highly structured 'C' program spending the
majority of its time pushing and poping registers, passing arguments,
and returning a whole byte (or word or more) for a true/false condition.
It seems to me that all this time could be spent running someone else's
program - allowing more programs to run (and faster). However, one of
these days, disk drives will be real fast, and Ram will be real fast,
and the CPUs will run at gigahertz clock speeds - then who cares (we all
will even then...).
Have a heart, this stuff is my opinion, and my observations (I am entitled
to my own opinion), and send any death threats, etc. directly to me via
mail.
Mike Schwartz @ 3Com Corp.
P.S. BASM was originally developed for the C64 and Atari 800 computers
by Computer Alliance of Granada Hills California. I wrote a functional
equivalent of BASM for the IBM PC (generating 6502 code), then wrote
a superset of it (included macros, and other bells and whistles). All
three compilers accept straight assembler language as input.
8086 BASM:
def strcpy .s1, .s2
mov si,s2
mov di,s1
while [si] -> [di] <> 0
enddef strcpy
Clayton Cramer
> there. Is 'C' really portable, or is UNIX pretty tough to port anyway
> (by pretty tough, I mean a few months' work)? Are other applications
> written in 'C' really portable? (I bet most are near impossible to
> port from UNIX to the 8086).
A project I am leading wrote 12000 lines of C in about four months on
a VAX running Berkeley 4.2 UNIX. Then we tried to port it to the IBM AT
running PC-DOS and Microsoft C V3.0. Six hours after we started moving
the source over, it ran. Perfectly. Is this portable?
> Is it worth it for portability to have
> programs that run at half the speed (or less) than the computer is
> capable of (or will it matter if they make computers go fast enough)?
Ask all those companies that right now are wishing they could move their
8088 assembler language programs over to the Atari.
> Should it matter that a language called Action (similar to BASM) on a
> toy Atari 800 can compile a megabyte of source code (a little overstated)
> in the time any 'C' compiler I have seen can compile "Hello, World"?
> Is portability a reality? I can port a BASM program from the C64 to
> the C128 to the Atari 800 to the Apple II faster than a 'C' program can
> be ported from Unix to the IBM PC, and we are talking about 20 MILLION
> machines. Will a 'C' program ever be ported from the Amiga or ST to
> anywhere else (the Amiga OS has maybe 400 functions not supported by
> Unix)? How many are worth porting the other way?
>
One of the reasons that the Atari ST uses GEM is because GEM provides
a consistent interface for application programs, and GEM works on the
IBM PC family as well.
> I have not been trying to flame 'C', which is a Ratfor for PDP-11 assembler
> language, so please nobody take this as a personal attack against some
> hallowed institution. What I have been trying to do is provide some
> food for thought for those of you out there who want to write compilers.
> The world needs more Modula and Pascal and 'C' compilers like we all
> need another hole in the head. How about using 'C' to bootstrap a
> new language that fits a machine's architecture reasonably.
>
What we need are 'C' compilers that WORK! Microsoft V3.0 is real good.
It is the only C compiler for the PC family I have seen that is trustworthy
and useable. I just wish it was available for the Atari.
> I shudder to think of a highly structured 'C' program spending the
> majority of its time pushing and poping registers, passing arguments,
> and returning a whole byte (or word or more) for a true/false condition.
Sounds like you are objecting to structured design. Maybe building
video games structured design isn't important because video games, while
complicated, aren't subject to the levels of maintenance and enhancement
that other products are. (If it doesn't do what you expected when you
move the joystick, you can just define a new "rule" for the game).
Frank Adams
In article <4...@kontron.UUCP> cra...@kontron.UUCP (Clayton Cramer) writes:
>> Is it worth it for portability to have
>> programs that run at half the speed (or less) than the computer is
>> capable of (or will it matter if they make computers go fast enough)?
>
>Ask all those companies that right now are wishing they could move their
>8088 assembler language programs over to the Atari.
As an employee of such a company (although there is not (yet) any strong
desire to run on Ataris), let me attempt an answer. Let me emphasize that
this is my answer, not that of my company.
Personally, I believe we would have been better off writing our product in
C, and I would certainly support writing any new products in C. (The
improvements in processor speed do make a difference.) However, if writing
it in C would have meant it ran half as fast, it would have been a mistake.
If Multimate(tm) had run half as fast, it would not have sold, and we would
not be in business. Better a salable product in a limited market than an
unsalable product in an unlimited market.
Frank Adams ihpn4!philabs!pwa-b!mmintl!franka
Multimate International 52 Oakland Ave North E. Hartford, CT 06108
x0705
>
>In article <4...@kontron.UUCP> cra...@kontron.UUCP (Clayton Cramer) writes:
>>> Is it worth it for portability to have
>>> programs that run at half the speed (or less) than the computer is
>>> capable of (or will it matter if they make computers go fast enough)?
>>
>>Ask all those companies that right now are wishing they could move their
>>8088 assembler language programs over to the Atari.
>Personally, I believe we would have been better off writing our product in
>C, and I would certainly support writing any new products in C. (The
>improvements in processor speed do make a difference.) However, if writing
>it in C would have meant it ran half as fast, it would have been a mistake.
Obviously, it makes sense to write it portably in C first - if some parts of it
are too slow, you can rewrite them afterwords. Meanwhile, you'll have done
rational things with data structures, algorithms, user interfaces,...
things that are a real pain in assembler. The system performs a lot better
when you write it correctly in a semi-fast language than when you write a poor
program in a faster language.
--
# Bill Stewart, AT&T Bell Labs 2G-202, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs
Mike Schwartz
I agree that 'C' makes a good "prototyping" language - you might be able
to formulate a program fairly quick. However, I believe that user-
friendliness has become a big issue in the software world, and that
a speedy program that takes less resources is much friendlier than the
'C' equivalent.
People have mentioned data structures and other such things as a benefit
of high level languages. Why not have an assembler with data structures?
IBM has one for the IBM PC...
I agree that people time is very important, but not programmer time. I
don't see how it is beneficial to save a programmer a month's worth of
work when the result is a program that costs the rest of the world that
uses it a MUCH larger agregate time spent waiting for a slower program
to load and execute (all those extra seconds multiplied by all those
users of the program add up!). Laziness is what this sounds like to me.
If a program is worth being used by many people, I don't see how it is
any advantage to write it in 'C' (other than portability).
Has anyone out there ever implemented the same program twice? I have,
and I find that the second time is always much faster and much better
than the first (I learn from my mistakes...) Writing a program in 'C'
first, then recoding in Assembler sounds a lot better to me than just
the 'C' version.
A lot of UNIX gurus tell me how nice it is to have all the nice little
filter programs, etc., that UNIX provides. For every 100 GREPs that
a programmer does, he probably wastes a minute or two. In 1 year, how
many man hours are lost throughout the country just running grep?
The last point that I would like to make is about libraries. The main
benefit to using a high-level language is the fancy library routines
that automatically get linked in and make your programs larger. I like
some of the library routines, and I have implemented many as assembler
language routines. These routines are my own library, which makes my
assembler coding very brisk. The other high-level features like
if-then-else, etc., are simple macros to a structured assembler, so
that stuff is not lost.
I would like to close by giving an example of how I think most programmers
can hand optimize 'C' programs, producing smaller and faster object code.
The basic premise is that 99.9% of a program does not require recursion or
re-entrancy. I do agree that some things are highly dependant on recursion
or re-entrancy, so this will not work in those cases.
#define func(a,b,c) {parm1=(a); parm2=(b); parm3=(c); func_entry(); }
func_entry() {
/* uses parm1, parm2, and parm3 (statics) instead of auto */
.
.
.
}
I would like to dispell a misconception about myself, too. I have been
programming in 'C' for over 10 years. I used to work for a company called
Systems Marketing Consolidated, from which a few guys left and made a
company called "Lattice". I never used Lattice 'C' until recently on the
PC, but I used the same compiler (mini-computer host, target) in '80 -
I may have been the first to use it. I hope this lends a little more
credability to my arguments - I have a lot of experience in both
assembler and 'C' (and others), and I can see merits in both approaches.
Just look at the MAC and how slow it is (ruins the friendly interface) and
look at MS DOS (written in assembler), and the difference is 180K of object
code (MS DOS is pretty small), and a faster environment (a vax running UNIX
is slow as molasses even with 1 user). Granted the Mac was written in
PASCAL.
Apple shouldn't have to come out with a new faster Mac. The only reason they
do is because they didn't do it right (in assembler) the first time (when
they used a high-level language). Programmers should be paid to write
the best programs possible (I do not believe in doing it slowly) if these
programs are to become products.
I still do not understand why assembler language coding is associated with
slower development or less maintainability - if you have good programmers,
it is not a problem. 'C' programmers actually require less knowledge of
machine architecture, and therefore do not generate the most efficient programs.
On the other hand, I can see that some programs are only run once (to solve
some problem that would take much longer by hand), and I have no preference
about what language they are written in. All I know is that the faster
my assembler or compiler is, the more productive I am. This leads me to
believe that it works that way for other programmers too.
Stavros Macrakis
> speedy program that takes less resources is much friendlier than the
> 'C' equivalent.
Sometimes speed and size matter, sometimes not. Often other things
are more important, such as functionality, capacity, and time to
market.
> Why not have an assembler with data structures?
It's called C.
> I agree that people time is very important, but not programmer time. I
> don't see how it is beneficial to save a programmer a month's worth of
> work when the result is a program that costs the rest of the world that
> uses it a MUCH larger agregate time ...
The `world' may not be willing to wait the extra 6 months of
development time, and will probably not tolerate the additional bugs.
It depends on the market. If you're selling the fastest program in a
category, you may want to write much of it in assembler. If, on the
other hand, you want to be the first one out, or you're selling the
one with the most functionality, and you wouldn't be able to ship in
time if you wrote in assembler, you presumably write in a higher-level
language.
> The main benefit to using a high-level language is the fancy library
> routines that automatically get linked in and make your programs
> larger. ... The other high-level features like if-then-else, etc.,
> are simple macros to a structured assembler, so that stuff is not
> lost.
An interesting perspective. As for me, I'm rather fond of such
high-level language facilities as type checking, interface consistency
checking, sensible scoping rules, and so on, which have ZERO runtime
cost, as well as such facilities as machine independence, automatic
register allocation, ..., some of which cost a bit of machine
efficiency, others of which gain some (take a look at the output of
the PQCC compiler sometime and tell me you could have coded it up
better yourself). Much of your argument, I suspect, would go away
with better compilers.
Your example of `optimizing' C programs by using static rather than
stack storage is peculiar. As you say, your code precludes recursion
or reentrancy. On our 780, it also runs at about the same speed as the
stack, but is 4 bytes longer in the caller, and 8 bytes longer in the
callee. It has worse cache and paging behavior as well. I don't see
the advantage.
Note also that static parameter areas require you to provide space for
the entire possible call tree, while stack parameters need only the
size of the longest path to the root of the call graph. Alternatively,
you can overlap usage of the parameter areas. This is extremely
error-prone.
It's interesting that you should attribute the difference in speed and
size between MS-DOS and the Mac OS to the language in which they are
written. Without a comparison of the functionality, I don't see the
point.
Certainly there are cases where assembler can contribute efficiency.
In other cases, all it does is make development slower and more
expensive. And machine efficiency is not the only measure of the
value of software.
-s
Wrolf Courtney
[Go ahead - eat my shield!]
In the latest of this saga my...@3comvax.UUCP (Mike Schwartz) writes in
<4...@3comvax.UUCP>:
> Just look at the MAC and how slow it is (ruins the friendly interface) and
> look at MS DOS (written in assembler), and the difference is 180K of object
> code (MS DOS is pretty small), and a faster environment (a vax running UNIX
> is slow as molasses even with 1 user). Granted the Mac was written in
> PASCAL.
>
> Apple shouldn't have to come out with a new faster Mac. The only reason they
> do is because they didn't do it right (in assembler) the first time (when
> they used a high-level language). Programmers should be paid to write
> the best programs possible (I do not believe in doing it slowly) if these
> programs are to become products.
It will doubtless be news to Apple that they - or rather Bill Atkinson, Andy
Hertzfeld and a few others - wrote the Mac Toolbox and Operating System in
Pascal. They probably thought that they were writing in 68000 assembler all
that time ...
The real problem is disk io. Unfortunately there is no form of DMA in the Mac
except, of course, the screen. The disk io channels themselves (sorry about
my terminology) are rather appalling in performance, and have been allegedly
speeded up by a factor of 8 in the new MacPlus. On top of which the software
does no serious disk cacheing - in a recent discussion Andy Hertzfeld mentioned
that he uses a commercially available disk cacher.
Of course, the Mac is documented for Pascal programmers, and one presumes that
almost all applications programming will occur in languages at least as high-
level as C or Pascal. In fact, object-oriented languages are likely to make
the biggest impact - C++, Clascal and the like. Assuming that these marvelous
structured assemblers will have 5 times longer source code sizes than high-level
equivalents, I would like to see Mike Schwartz knock off 100,000 lines some
weekend for a moderate full-scale program.
Of course he will find it easier than his tricky little 100 liners - after all,
all you have to do is figure out which Toolbox call to make, push the parameters
onto the stack in the right order, then do an inline trap. Over and over again.
The optimisations that Schwartz mentions - that there is no need to code 95% +
of procedures as recursive and so on - could of course be implemented by a
good code generator in a good compiler.
FLAME ON
1. Get your facts straight before foaming at the mouth.
2. Bet you can't write 100,000 lines of code AND hand-optimise all of it
AND get it all to work. Never heard of critical code?
FLAME OFF
I will doubtless be assassinated one of these dark nights....
Wrolf Courtney philabs!sbcs!goedel!wrolf
CS Dept. SUNY at Stony Brook. NY
rex ballard
>> programs that run at half the speed (or less) than the computer is
>> capable of (or will it matter if they make computers go fast enough)?
>
>8088 assembler language programs over to the Atari.
Or anyone who is bound to PDP-11 emulation mode on a VAX because the macro
processor is integrated into the assembler. Structured assembler requires
a lot of macro definitions which are not always compatible. Even writing
m4 macros can lead to surpises.
rex ballard
then rewrite it in assembler. In support of this, the author claims:
A: the rewrite in assembler will be faster/more efficient.
B: the assembler will be more maintainable.
On point B:, studies have shown that the number of errors or changes is
exponentially related to the number of lines of code. One study indicates
that the average is one error per 1000 lines. Another indicates 1 change
(as a result of error or enhancement) per 25 lines. Both studies indicate
that this is requardless of language. The second study indicates exponential
increases in errors per module. There are also few 'static verification
tests' available in assembler. Lint on the other hand, provides such
capabilities even to the 'heuristic level'. Had lint not been written,
C would probably not be as popular as it is. Perhaps providing lint
with all compilers would reduce resistance to it in such arenas as
personal computers.
While it is true that assemblers may reduce time, the most common savings
are in the form of argument passing through registers rather than the stack.
This could be remedied through the compiler, frame oriented hardware
(such as CCI's 6/32), or other 'Automated approaches'. An assembler routine
which expects certain values in certain registers tends to imply higher
maintenence costs, since it is not always convenient or practical to
reserve/assign those registers explicitly. Transfers and alignment
of registers may actually offset the time saved using the assembler
module in the first place.
On point A:, ideally, all software should be written twice. Reality
seems to prevent that. If it is possible to rewrite, doing so in
the same language provides similar benifits, without adding the
possibility of mis-interpretation and new errors in translation.
Profilers can identify 'hot spots' where excessive time is being
spent. These are viable candidates for assembler or 'fast but no morals'
C code.
Certain problems like 'context switches' which involve explicit use of
specific registers (like the stack pointer), or 'jump tables' are
not practical in C, and have to be written in assembler anyway.
Calling a C routine from assembler is relatively easy, calling assembler
routines is harder but possible and practical for those 'really tight loops'.
Of course the same is true for any other 'high level language' of the
3rd generation type (Fortran, C, Cobol, PLM... compiled languages).
C just gives the programmer control at a much deeper level (pointers
with negative indexes...). About the only thing C doesn't do that
assembler provides is absolute addresses of variables (typically
port addresses, trap vectors, and registers). Perhaps these are
worth considering as improvements for C, but not for replacing the
compiler with a human being.
Fourth generation languages (Forth, SmallTalk, Neon...) may find
better ways of solving these problems, but this is still a new field
where good standards have yet to evolve. Eventually, we will see
a 'fourth generation' equivelent to C, or even Ratfor, which will
replace C the same way assembler replaced machine code and Fortran and
C replaced assemblers.
As to programmer time being more important than user time: To a point,
I would agree, but when looking at all the PC compatibles and seeing
how "XYZ software crashes on ABC's computer" because of 'fast assembler
routines' that weren't "vectored in", I wonder if the speed is really
worth all the lost business. Also, even though 'system response time'
may not be optimal, the interface, interactive nature of the work, and
the 'presentation level' interface are much more significant factors.
Dvorak keyboards, Mice, number of disk accesses required to complete a
search/grep and other hardware and software design issues have more to
do with the effecient use of 'User time' than the execution time of
the code (which represents less than 1% of the actual time on most systems).
In vertical market situations, where the customers needs change weekly,
the quicker you can get those changes made, the better. Is looking
through 100,000 lines of assembler quicker than looking through
5000 lines of C?
Bob Campbell
this 2 dollars) worth.
In article <4...@3comvax.UUCP> my...@3comvax.UUCP (Mike Schwartz) writes:
>I agree that 'C' makes a good "prototyping" language - you might be able
>to formulate a program fairly quick. However, I believe that user-
>friendliness has become a big issue in the software world, and that
>a speedy program that takes less resources is much friendlier than the
>'C' equivalent.
I don't agree that 'C' is a good prototyping language, as there are many
languages that provide faster Build/Debug/Rebuild cycles, and better
debugging tools. However most of these languages (lisp, smalltalk, icon,
snobal,...) are interpreted. Interpreted languages have in most cases the
advantages of less effort to create and run the program (no linkers loader
etc), better run time checking, and in some cases the code can be modifed
and a test restarted where it failed. The cost of interpreted languages
is at run time where the system runs much slower, but in some cases this
is ok as most of the time is spent waiting for user input.
As for friendlier, that is a releative (and also abused used term), to
some people friendlier means faster, to other's friendlier means easier
to understand and use, and to yet others friendlier means easier to
modify.
>... Why not have an assembler with data structures?
>IBM has one for the IBM PC...
With only a little effort most assemblers can create psuedo structures
using equates, or on MVS or CMS the assembler supports dummy psects
which can be used to generate record structures.
>I agree that people time is very important, but not programmer time.
This is not true, for example Teltone (where I work) is in hot water
because the system we are producing is not on time (two years late).
Many of the early mistakes we in the area of optimizing things which
we did not understand. About a year ago Management noticed that they
were in big trouble, and modified the climite such that it was most
important to get the code done on time and insure that it was correct,
many of the optimization efforts of the past were discarded. Large
parts of the system were discarded, and it appear that most of the
problems that happened since that time would not have happened if
we could have used a Higher Level Lanuage than 'C', something like
modula-2 or ada.
>If a program is worth being used by many people, I don't see how it is
>any advantage to write it in 'C' (other than portability).
Most the code at teltone runs on three different machines (VAX 750s,
PDP11/23, and Pyramid 90x) we can not afford to maintain three assembler
version of every program we write. It is quickest to write and debug
code on the pyramid.
>...the first (I learn from my mistakes...) Writing a program in 'C'
>first, then recoding in Assembler sounds a lot better to me than just
>the 'C' version.
Sounds like grunt work to me.
>...programmer does, he probably wastes a minute or two. In 1 year, how
>many man hours are lost throughout the country just running grep?
JUST THINK HOW MANY MAN YEARS ARE SAVED USING GREP. Why should I have
to scan 100 page stacks of printsouts looking for references to the
variable TRACER_RECORD.ESEQ. If the answer is I should know my own
code sorry but it was not my code to begin with.
I will not get into the MAC is slow, MS-DOS is better etc; debate, I
like my Mac, and would only trade it in for a sun, or a Xerox Machine
(amiga is real close).
Bob Campbell
LanguagesRUS
Save the world abolish assemblers :-) :-)
{uw-beaver,fluke,hplsla,dataio}!tikal!bobc
her...@umn-cs.uucp
<** Pet Flame On **>
Actually, it didn't hasn't always been impossible to construct
jump tables in C. In the Good ol' Days before 0 AL (After Lint),
the "goto" statement would take any operand as a destination.
A label simply had a machine address as a value, and "goto" simply
jumped there. Thus one could do things like:
foo() {
a:
bar(a);
}
bar (x)
{
goto x;
}
and blow one's stack out of the water. All kinds of unsavory things
were possible, and generally undesirable. Unfortunately, with the
coming of "strong typing" (and its concomitant weak ideas), the
type label got lost. One cannot type coerce a label to anything else,
nor anything else to a label. Very discouraging to those of us who
occasionally like to jump to arrays full of machine code (say, for
direct interpreters, etc.). Admittedly, these kinds of applications
are generally pretty rare, but doing it now requires an array of
procedure addresses, and one often has to use an enormous stack
if each procedure calls the next. This is may not be desirable if
there is no reason to return to the caller, as in tail recursion.
It's not optimized in C compilers like it often is in lisp.
Having a type "label" for type coercions, like the type "void",
would be very useful to me in occasional, rare applications.
Oops! Don't get me wrong -- I like strong type typing in practice.
It has saved me countless bugs which would have had me stymied for
days. However, the "theory" of strong typing as it exists seems
very weak. Maybe someday, it will get better, but since it appears
closely related to semantic issues, I doubt it.
<** Pet Flame Over **>
Robert Herndon
...!ihnp4!umn-cs!herndon
Craig Wylie
>>I agree that 'C' makes a good "prototyping" language - you might be able
>>to formulate a program fairly quick. However, I believe that user-
>>friendliness has become a big issue in the software world, and that
>>a speedy program that takes less resources is much friendlier than the
>>'C' equivalent.
>I don't agree that 'C' is a good prototyping language, as there are many
>languages that provide faster Build/Debug/Rebuild cycles, and better
>debugging tools. However most of these languages (lisp, smalltalk, icon,
>snobal,...) are interpreted.
You miss out shell (be it sh, csh, ksh, msh etc ....)
One of the many uses of shell programming must be as a fast prototyping
language. It is quite easy to convert the resultant code into C (and I
have discovered into Modula-2) at a later time.
We are often reminded that optimisation at too early a stage is dangerous,
shell programming offers an environment that allows the fast production and
debugging of programs without the problems of using linkers, debuggers etc...
What would people think about the introduction of structured data types
into shell ?
Shell is also both polymorphic and functional (using evaluation quotes),
sounds pretty good to me.
>Many of the early mistakes we in the area of optimizing things which
See comments above
Craig.
--
UUCP: ...!seismo!mcvax!ukc!dcl-cs!craig| Post: University of Lancaster,
DARPA: craig%lancs.comp@ucl-cs | Department of Computing,
JANET: cr...@uk.ac.lancs.comp | Bailrigg, Lancaster, UK.
Phone: +44 524 65201 Ext. 4146 | LA1 4YR
Project: Cosmos Distributed Operating Systems Research Group
Jon Mauney
If anyone has not seen enough argument against this statement,
take a look at ITT Telecom, which just abandoned its digital switch
for the US market and laid off 1200 employees. The problem was
not a slipped deadline but a demand that peaked too soon, but
the effect is the same. ITT's switch might have been the great
product to blow the others away, but the phone companies are
buying now, and the product wasn't ready.
If they'd been programming in SETL :-) they might have saved it.
--
Jon Mauney, mcnc!ncsu!mauney
North Carolina State University
Doug Pardee
> > Why not have an assembler with data structures?
>
> It's called C.
Balderdash. C is not a substitute for assembler. While C is basically
as flexible as assembler, it is nowhere near as efficient. If the
application demands efficiency, there is still no alternative to
assembler.
As to the feasability of structured assemblers, IBM's ALC assembler for
the 360/370/30xx/43xx series computers has had data structures since the
mid '60s. By the mid '70s IBM and others had also developed macro
packages which provided if/else/endif, do while, and similar control
structures.
> The `world' may not be willing to wait the extra 6 months of
> development time
I hear this "gotta be first to market" argument a lot. But I would like
to point out that historically, the "first to market" loses out. IBM's
PC was many years behind other 8-bit CP/M-type systems, but look where
it is now. To take a software example, Context MBA was a spreadsheet
program for the IBM PC. It was written in Pascal, and was on the market
long before (assembler coded) Lotus 1-2-3. Within a couple months after
1-2-3 was introduced, Context MBA was a dead product because 1-2-3 ran
a lot *faster*. Lotus is now well off financially, and Context is bust.
[A "where are they now" discussion of other pioneer products might
be interesting, but net.lang doesn't seem the appropriate place...]
--
Doug Pardee -- CalComp -- {hardy,savax,seismo,decvax,ihnp4}!terak!doug
Doug Pardee
You almost got the point... "if you have good programmers". You see, a
good programmer costs money to hire. But almost any twit can eventually
mangle a C program around enough that it looks like it does something
similar to what it was supposed to do. And that twit will be glad to
work for a lot less money than good programmers command.
When a company decides to develop a product in C or Pascal, it's because
they know that they can hire a bunch of trained monkeys to do the job,
and pay them in bananas. Of course the resulting product won't be as
good as if it was done in assembler, but the company is looking at the
bottom line.
A company makes a profit by having sales>expenses. One way to do this
is to have low sales and even lower expenses. That's the way that a
company doing a product in C expects to make a profit. [For many
companies, there is no choice because of limited capital.]
Other companies, however, accept high expenses offset by even higher
sales. Those are the companies that hire me, and that's why I earn 2 to
3 times as much as C programmers. Sure, I can program in C. I can also
bag groceries and haul trash. As you can see, I have a number of
marketable skills :-). But the profession I choose is the one that
gives me the most challenge, opportunity, and rewards.
Now for the bottom line for programmers: if you're a trained monkey,
then you'd better stick with C and Pascal. But if you're really good,
the fun, big money, and job openings are in assembler programming.
Col. G. L. Sicherman
> exponentially related to the number of lines of code. One study indicates
> that the average is one error per 1000 lines.
You don't mean "exponentially," do you? (Though it applies to _some_
programmers I know....)
--
Col. G. L. Sicherman
UU: ...{rocksvax|decvax}!sunybcs!colonel
CS: colonel@buffalo-cs
BI: csdsicher@sunyabva
Bob Campbell
In article <10...@terak.UUCP> doug writes:
>Balderdash. C is not a substitute for assembler. While C is basically
>as flexible as assembler, it is nowhere near as efficient. If the
>application demands efficiency, there is still no alternative to
>assembler.
This also is not true, it is not fair to compare generic languages like
'C' vs assembler. Why not take a specific example and say the Consular
'C' compiler is not as efficient as my foobar assembler. (we have a
8086 assembler which is a dog both in speed of assembly and support of
macros). I still feel that is it possible to have optimizing compilers
which will on the average generate code which is 2 times better then the
average human produced code. (Human should read experienced assembler
programmer)
Also to go back to a earlier point about Apple's Mac and assembler
programming the improvements in the new ROM where in some cases the
application of compiler style object code improvements to the assembler
code. Specificly unrolling some loops which can be done easily by a
optimizing compiler.
>........
>program for the IBM PC. It was written in Pascal, and was on the market
>long before (assembler coded) Lotus 1-2-3. Within a couple months after
>1-2-3 was introduced, Context MBA was a dead product because 1-2-3 ran
>a lot *faster*. Lotus is now well off financially, and Context is bust.
Yet another interesting argument for which there are many counter examples:
To take the easiest lets use UNIX*, unix is very popular right now in
spite of the fact that it is slower than traditional operating systems
written in in assembler. It is very popular because of it's user
interface (the shell, pipes, simple i/o interface, i/o redirection,
etc), and because it is portable. Given your analysis UNIX would be
"bust" but it is not, and in fact it is getting stronger.
Another factor which you are not considering is the "RISC**" factor.
The RISC concept implies that having instructions which require special
programming in assembly language, are the sign of a flawed computer.
This is because the presence of the special instructions which can not
generaly be used by a compiler, are instructions which are not used
very often. The presence of these special instructions slows down the
operation of the computer on the normally executed instructions (mostly
move, and compare instructions). The net result is that the machine
runs faster overall with out the special instructions.
Some RISC computers have instructions which do not allow for easy
programming in assembler. Wirth's lilth (maybe not a RISC, but still a
interesting concept) machine in fact is built with the assumption that
only code generated by a compiler would run on the machine (the machine
does not check for expression stack overflows).
To further the example the pyramid (which I am using to write) this is
a Unix machine for which there is NO SUPPORT for the assembler.
In spite of this lack of assembler it is always faster then any other
machine that we at teltone have access to.
Bob Campbell
Teltone Corp.
Kirkland Washington.
uw-beaver \
fluke -+- tikal!bobc
dataio /
[Time for cute remark]
Lets make smarter machines to run slower software faster.
*Unix is a Trademark of some AT&T division.
**Reduced Instruction Set Computer.
Wayne Throop
Sarcastic (GASP). You have been Warned. ]
> Now for the bottom line for programmers: if you're a trained monkey,
> then you'd better stick with C and Pascal. But if you're really good,
> the fun, big money, and job openings are in assembler programming.
> --
> Doug Pardee -- CalComp -- {hardy,savax,seismo,decvax,ihnp4}!terak!doug
Gee, and I thought the trained monkeys were the ones doing the peephole
optimizations by hand, screwing around deciding if a few shifts and adds
are better than a multiply this time, and similar shenanigans. It's so
much clearer to me now! Worrying about algorithms and data structures
is for lowly technicians! The *rewarding* and *interesting* (and
high-paying) work is translating these ideas into *raw* *bits*. Just
imagine how rewarding and stimulating it would be to actually *key*
*the* *bits* *into* *a* *front-panel*! I could even do multiplication
in hex in my head! Oh, rapture! Oh, joy! What a good use for a mighty
programming talent!
And no more of this dez*ghust*ing *compiler* writing, where you figure
out what optimum code patterns are *once* and then let a (yuck)
*computer* do it, oh no! I mean, I wouldn't even trust a computer to
run my microwave oven, let alone generate *code*!
[ Uh... *how* much more did you say I get paid if I do this kinda crap? ]
--
Dreyfus: He's got no more intelligence than a pet minky!
Psychiatrist: What?
Dreyfus: What?
Psychiatrist: You said... "minky"?
Dreyfus: Damn him! Now he's got *me* doing it!
--
[The invention of the bagpipe (read in your best Scottish accent)]
Le' me see, whut ken Ah doo tu meik a rrreely dez*ghust*ing
myooozical instrooment? Sumthin' rrreally iirrritatin'. Ah woonder
what woud hoppun if Ah blew into a vakyoom cleanerrr....
[I'd give credit for this, but I can't remember where I heard it]
--
Wayne Throop at Data General, RTP, NC
<the-known-world>!mcnc!rti-sel!dg_rtp!throopw
Frank Adams
>We are often reminded that optimisation at too early a stage is dangerous,
>shell programming offers an environment that allows the fast production and
>debugging of programs without the problems of using linkers, debuggers etc...
>
>What would people think about the introduction of structured data types
>into shell ?
>
>Shell is also both polymorphic and functional (using evaluation quotes),
>sounds pretty good to me.
You might instead take a look at REXX. This is language designed for
command control which is not intended for a specific machine. (Programs
written in it are not portable between OS's, of course.)
I have no idea whether a UNIX(tm) version is available.
Frank Adams ihnp4!philabs!pwa-b!mmintl!franka
Frank Adams
>> if you have good programmers, [assembler] is not a problem.
>
>You almost got the point... "if you have good programmers". You see, a
>good programmer costs money to hire. But almost any twit can eventually
>mangle a C program around enough that it looks like it does something
>similar to what it was supposed to do. And that twit will be glad to
>work for a lot less money than good programmers command.
You have it half right. Companies willing to pay for good programmers will
get their code produced in less time, at less cost, and it will work better,
without regard to what language(s) are used to write it. You see, the
good programmer working in C will write a good, clean program which does
exactly what it is supposed to, and take a lot less time about it. (Because
(s)he doesn't waste time mangling it.)
I believe that given good programmers, you will get good code a lot faster
in a higher level language than in assembler. Unless you need the ultimate
in performance, you don't need to use assembler. Even then, it usually
suffices to write a few key routines in assembler, and leave the rest in
a higher level language.
Comparing products written in assembler by good programmers with products
written in higher level languages by bad programmers is comparing apples
and oranges.
Frank Adams ihnp4!philabs!pwa-b!mmintl!franka
col...@ellie.uucp
> > On point B:, studies have shown that the number of errors or changes is
> > exponentially related to the number of lines of code. One study indicates
> > that the average is one error per 1000 lines.
>
> You don't mean "exponentially," do you? (Though it applies to _some_
> programmers I know....)
> -- Col. G. L. Sicherman
What do you know about it? Considering the amount of implosive inter-
connectedness of a large program, the bug rate probably _is_ exponential.
cr...@dcl-cs.uucp
>>
>>Shell is also both polymorphic and functional (using evaluation quotes),
>>sounds pretty good to me.
In article <11...@mmintl.UUCP> fra...@mmintl.UUCP (Frank Adams) writes:
>You might instead take a look at REXX. This is language designed for
>command control which is not intended for a specific machine. (Programs
>written in it are not portable between OS's, of course.)
>
>I have no idea whether a UNIX(tm) version is available.
REXX was the IBM replacement for that abomination of a command language
EXEC-2 which used to exist on VM/CMS. I think REXX comes with release
3 of CMS (I don't know where else it can be found in the IBM
environent).
One of the problems I have found with REXX is that it is particularly
IBM suited, not really UNIX suitable at all. Most of the functions
are built in and it does not contain the equivalent of the evaluation
quotes. It does contain named sub-routines which is a big advantage
over csh and vanilla Bourne shell however later versions of sh do
include shell functions. Any body interested in fast prototyping
in shell might take a look at msh from Mike Burrows at Cambridge
(m...@uk.ac.cam.cl). You require source licence unfortunately. This is
an enhanced Bourne Shell. The command line interface is a complete
line editor to allow WYSIWYG editing of the command line (ie no more
!!:s/fu/bar/ type syntax).
Mike Schwartz
Perhaps (I do mean perhaps) MicroSoft Basic is a better prototyping environment.
As a matter of fact, the basic runs on lots of different CPUs, is about the same
age as Unix, and can even be compiled. With newer and better computers
becoming available, the language has become quite powerful, including such high
level constructs as windows and graphics primitives.
Sounds like these 'C' shells are real good at prototyping 'C' programs.
Mike Schwartz
P.S. I do not program in basic, but I am aware that the MicroSoft Basic
interpreters and compilers exist.
da...@ztivax.uucp
Basic forces you to build something sans data strcutures, sans control
structures, pure vomit.
Use somthing that lets you THINK about the problem, not that you are
running out of space to the next line number... And what was that
variable for???
Even if you are going to implement in assembler (ESPECIALLY if you are
going to implement in assembler!!) you should have the concept and the
algorithm right!!!!!!!!!!!!!!!! BASIC clouds the issue so severley
that you wont be able to do it.
Real men use 4th generation languages...
seismo!unido!ztivax!david
Karl Tombre
>NO NO NO!! PLEASE NOT BASIC!!
>
>Basic forces you to build something sans data strcutures, sans control
>structures, pure vomit.
No, it does not force you, only makes it easy to construct such vomit.
>Use somthing that lets you THINK about the problem, not that you are
>running out of space to the next line number... And what was that
>variable for???
And why not think about the problem BEFORE beginning to program?
>Even if you are going to implement in assembler (ESPECIALLY if you are
>going to implement in assembler!!) you should have the concept and the
>algorithm right!!!!!!!!!!!!!!!! BASIC clouds the issue so severley
>that you wont be able to do it.
Here is the main point. Yes indeed you must have your algorithm right. But
if you have a structured, clear algorithm, you can write a BASIC program
which is not pure "vomit". Of course it won't be as well implemented as in
PASCAL, C or something like that, but IT IS POSSIBLE TO PROGRAM IN A CLEAN
WAY WITH BASIC. Some hints : put in your comments a description of EVERY
variable (my rule : between 50% and 70% of the code should be comments),
NEVER use the same variable for two different things, use SUBROUTINES in
which you comment about input and output (no undocumented side effects),
use GOTOs only when you are compelled to do it (in if then else structures
for example), separate your program into distinct parts, ...
I am of course totally aware of the great lacks of BASIC, but the main
reason for the many bad BASIC programs available is that so many
self-learned programmers have been around generating complete trash.
>Real men use 4th generation languages...
Real men think before they program. But indeed it is much better to use high
level languages.
--
--- Karl Tombre @ CRIN (Centre de Recherche en Informatique de Nancy)
UUCP: ...!vmucnam!crin!tombre or ...!inria!crin!tombre
COSAC: crin/tombre
POST: Karl Tombre, CRIN, B.P. 239, 54506 VANDOEUVRE CEDEX, France
Les plus desesperes sont les chants les plus beaux,
Et j'en sais d'immortels qui sont de purs sanglots.
Alfred de Musset.
Scott Dorsey
>In article <790...@ztivax.UUCP> da...@ztivax.UUCP writes:
>>Basic forces you to build something sans data strcutures, sans control
>>structures, pure vomit.
>
>No, it does not force you, only makes it easy to construct such vomit.
I am sorry. But any language that does not allow parameter passing
has something seriously wrong with it. Even most assemblers give you
some 'ram it on the stack and call' stuff.
(From a former, self-taught BASIC programmer who has seen the light)
--
-------
Disclaimer: Everything I say is probably a trademark of someone. But
don't worry, I probably don't know what I'm talking about.
Scott Dorsey " If value corrupts
kaptain_kludge then absolute value corrupts absolutely"
ICS Programming Lab (Where old terminals go to die), Rich 110,
Georgia Institute of Technology, Box 36681, Atlanta, Georgia 30332
...!{akgua,allegra,amd,hplabs,ihnp4,seismo,ut-ngp}!gatech!gitpyr!kludge
Tom Haapanen
>Here is the main point. Yes indeed you must have your algorithm right. But
>if you have a structured, clear algorithm, you can write a BASIC program
>which is not pure "vomit". Of course it won't be as well implemented as in
>PASCAL, C or something like that, but IT IS POSSIBLE TO PROGRAM IN A CLEAN
>WAY WITH BASIC. Some hints : put in your comments a description of EVERY
>variable (my rule : between 50% and 70% of the code should be comments),
So it'll be well documented vomit... :-)
>NEVER use the same variable for two different things, use SUBROUTINES in
>which you comment about input and output (no undocumented side effects),
Input and output from subroutines? But BASIC does not allow formal
parameters or returned results! Having to pass input in global
variables is gross and practically prevents recursion.
>use GOTOs only when you are compelled to do it (in if then else structures
>for example), separate your program into distinct parts, ...
if...then...else should NOT need a goto and it shouldn't have one forr
clarity. Naturally, if the language is brain-damaged enough to be
missing the else, you'd need a goto.
<donning asbestos suit>
In my opinion any reasonable programming language has the following
features:
- reasonable (!) syntax and variable name length
- named subroutines, with parameters and results
- dynamic local storage allocation (to allow for recursion)
- control structures: if...then...else, while...end,
for...end, case
- data structures: arrays and records, with dynamic
allocation possible (to allow variable-sized structures)
A case can be made for languages that are missing one of the five
(such as APL2 etc.) but "normal" BASIC only has the first feature!
There are BASICs that have four of the five, but then they are more
like Pascal than BASIC anyway.
<removing asbestos suit>
\tom haapanen / watrose!tohaapanen
university of waterloo ..!watmath <-- watmum!tohaapanen
\ watlion!tohaapanen
I am one in ten, a number on a list
I am one in ten, even though I don't exist
No-body knows me, though I'm always there
A statistical reminder of a world that doesn't care (c) UB40, 1981
Roger Klorese
> I am sorry. But any language that does not allow parameter passing
>has something seriously wrong with it. Even most assemblers give you
>some 'ram it on the stack and call' stuff.
Who SAYS BASIC doesn't allow parameters?? I GREW UP on Dartmouth BASIC.
It sure does. Now, this Microswill thing, I dunno...
(Or try "True BASIC"...)
--
*** Speak for the company? Naaaah, it's hard enough speaking for ME! ***
... "What were you expecting, rock'n'roll?"
Roger B.A. Klorese
Celerity Computing, 40 Speen St., Framingham, MA 01701, (617) 872-1772
UUCP: seismo!harvard!bu-cs!celtics!roger, ucbvax!sdcsvax!celerity!celtics!roger
ARPA: bu-cs!celtics!ro...@harvard.ARPA, celerity!celtics!ro...@sdcsvax.ARPA
Kayvan Aghaiepour
>
>
>seismo!unido!ztivax!david
Real men can program in whatever language they are given!
Real men crank out structured assembly code (Yes! Such an animal exists!
Use lots of procedures, have *very* local loops, and comment your
code like a madman!).
Real men can make Basic look pretty.
Real men *can* use fourth generation languages, and probably would,
given the chance, but they don't *need* to use them. Unlike so
many wimps who cringe at the thought of using languages like BASIC or
assembler, Real men just do it; and they do it right.
And don't anybody try to give me the academic definition of structured
languages. I know what control structures are necessary to make a
language structured in that sense. Still, one can put a *great deal*
of structure by using certain methods of coding, and, most importantly,
using one's brain while programming.
---Kayvan
Mike (I'll be mellow when I'm dead) Meyer
>In my opinion any reasonable programming language has the following
>features:
> - reasonable (!) syntax and variable name length
> - named subroutines, with parameters and results
> - dynamic local storage allocation (to allow for recursion)
> - control structures: if...then...else, while...end,
> for...end, case
> - data structures: arrays and records, with dynamic
> allocation possible (to allow variable-sized structures)
>
You forgot one very important one:
- data abstraction: a way to package a set of data structures and
routines into a single catagory.
[I know, I know - that isn't nearly what data abstraction is about. You try
and define it, including the correct typing magic, in two lines!]
When it comes to subsets, I'm willing to forgive almost anything, as long as
the language providesd some facility suitable for the problem at hand that
makes it easier to use than anything else I can get my hands on :-).
Still looking for a reasonable language,
<mike
Mike Schwartz
Pick up a book on MicroSoft Basic for the PC before you rant and rave about
Basic being vomit. The whole point I originally tried to make about
Basic is that it is extremely well refined and that it has as many man
hours of improvements made to it during the same time Unix has been refined.
Another point you seemed to miss is that the development environment for
Basic is quite good. You can stop your program, display variables, patch
the SOURCE CODE, and eliminate long boring compilations. Then when the
program logic is complete, it can be compiled ONCE and it will run
pretty damn fast.
<time for my asbestos suit>
If you want to talk about well documented vomit, I want to talk about
not-so-well documented vomit - Unix. The 'C' programming language is
proof that structures like if..else.. and while...endwhile do not necessarily
make the best programs. I peruse Unix sources occaisionally and I am
appalled at how UNREADABLE they are and I just do not see how anyone can
call 'C' a readable language. As a matter of fact, the unix sources I
have seen (BSD 4.1) have exactly one comment per file, have variables that
have an average of 4 characters per name, and only the well documented
library routines are decernable without lots of time spent following the
logic of the programs step by step.
In 'C', when you see a call like:
w=opnwndw(xqtnm);
the only way you can tell what it does is by using grep to find out
where the function is defined and if you are lucky, it will be documented.
At least in Basic, all of the keywords are WELL KNOWN, and no two programmers'
opnwndw() functions are different (the language defines the call), and the
language (Basic) tends to be geared toward using whatever hardware the
interpreter is implemented on in a easy to use way. Not many implementations
of Unix (written in 'C') have been ported to machines and really use the
hardware - READ ON - I have not seen a compiler that will use the string
functions that the 808x family of processors provide. These kinds of
instructions (LODS, STOS, etc.) are what makes the processor FAST.
<can I take off my suit?>
Now, before I finish, I would like to point out that I actually have
presented CONCRETE examples of why I think 'C' has serious problems. I have
not even mentioned how big or slow 'C' programs are (the downfall of
Unix as a standard). To say that a language is VOMIT because it does
not have if...then...else... kind of structures just shows that some
people do not use the proper procedures for evaluating the worth of
a language.
One last point. Structured assembler language, as I know it and have
implemented it, does have if...else...endif... and all the rest of
the structured language constructs, including parameter passing. It just
uses the most appropriate addressing modes for the target processor - by
definition. There are 0 (count 'em ZERO) bytes of runtime hogwash appended
to the real code that you want, and there is only the slightest difference
between the code generated and the code that I would generate by hand.
If you speak 8086, the following "IF" statement illustrates structured
assembler language:
if es:[bx] == 10 then
. print "hello, world"
else
. print "goodbye world"
. mov ax, 3100
. int 21H
endif
The keywords "if", "else", and "endif" are recognized directly by
the assembler and are not macros. "print" can be a macro or a function
call, however the programmer desires. Libraries are kept in source
format but may be linked in using a linker.
mike schwartz
3Com Corp. (usual disclaimers apply)
"real men get the job done"
Paul Asente
>parameters or returned results! Having to pass input in global
>variables is gross and practically prevents recursion.
>if...then...else should NOT need a goto and it shouldn't have one forr
>clarity. Naturally, if the language is brain-damaged enough to be
>missing the else, you'd need a goto.
><donning asbestos suit>
>
>In my opinion any reasonable programming language has the following
>features:
> - reasonable (!) syntax and variable name length
> - named subroutines, with parameters and results
> - dynamic local storage allocation (to allow for recursion)
> - control structures: if...then...else, while...end,
> for...end, case
> - data structures: arrays and records, with dynamic
> allocation possible (to allow variable-sized structures)
>
>A case can be made for languages that are missing one of the five
>(such as APL2 etc.) but "normal" BASIC only has the first feature!
>There are BASICs that have four of the five, but then they are more
>like Pascal than BASIC anyway.
>
><removing asbestos suit>
Ragging on BASIC seems to be everyone's favorite activity. Unfortunately
they seem to be fixated upon BASIC-1966, not BASIC-1986. Yes, early BASICs
were pretty primative, but remember the environment--very fast turnaround
small programs for beginning programmers. It's very easy to look back
upon the various decisions that were made in the design and laugh from a
vantage point of twenty years later, but is that fair?
It isn't, especially since BASIC has been an evolving language from the
start. Early compiler technology couldn't handle complicated stuff and
still be fast. As technology improved, so did BASIC. (Side note:
Contrary to popular belief, BASIC was not designed as an interpreted
language.) Modern BASIC has separately compilable subroutines (actually,
they've been in the language since at least the early 70's), variable length
identifiers, recursion, "modern" control structures, exceptions, and
graphics. It still has many of the good features from early BASICs, some
of which are much better than what you find in Pascal: easy-to-use I/O,
dynamic strings, simple data types (is the distinction between integer
and real that important for beginning programmers? I think not.).
I'm not claiming that BASIC is the ideal language, or that it's the best
language to use for large projects. But as a teaching language and a
language for writing quick throwaway programs it is a very reasonable
choice.
-paul asente
ase...@cascade.ARPA decwrl!glacier!cascade!asente
Colin Kelley
writes. If you've got to use BASIC, that's the way to do it. Typical program:
100 GOSUB 5000 ' Big comment here saying what 5000 does
200 GOSUB 6000 ' another big comment
300 GOSUB 7000 ' etc...
500 END
...
His programs typically do very little in lots of space, but they're not
bug-ridden! And it's usually pretty obvious that the programs are inspired by
(if not directly converted from) PASCAL...
Of course, one of the MANY problems with BASIC is that if this program has to
do anything other than a simple demo, it'll do it so slowly that it's useless.
But even a seventh grader can show you how to speed it up:
- delete all those damn comments,
- shorten variable names to 1 or 2 characters,
- remove all unnecessary blanks (like for indenting),
- change the subroutines to inline (!) code,
- get rid of the variable name in all NEXT statements,
- and then combine lines together right up to 255-byte-per-line limit!
But of course, seventh graders are experienced BASIC programmer already; they
know to write their programs like this from the beginning! (And of course,
they run a global renumberer every couple minutes!)
As you can probably tell, I've been through this stage. Fortunately, though,
I followed it through long enough to write long, poorly-written, bug-ridden,
useless programs. I found that impossible to avoid. But when I took my first
PASCAL course about 5 years ago, I saw the light! I was already an assembly
language hacker by then though, so I found it annoying not to be able to get
to the low-level stuff when I needed to... then... you guessed it... C!
Now I'm a happy programmer.
How many other people out there started with BASIC? I'm curious if there are
other people who wound up avid BASIC-haters precisely because it was the first
language they learned...
-Colin Kelley ..{psuvax1,pyrnj}!vu-vlsi!colin
BTW: don't interpret my first paragraph as a compliment to Peter Norton.
The man obviously has one of the biggest egos around already! (Witness all
his products, even back in the early days of PC magazine when he could only
afford a small ad, that invariably show his picture, with his sleeves rolled
up, ready to take on the world...)
Tim Smith
>>Then it would be well documented vomit.
>
>Pick up a book on MicroSoft Basic for the PC before you rant and rave about
>Basic being vomit. The whole point I originally tried to make about
>Basic is that it is extremely well refined and that it has as many man
>hours of improvements made to it during the same time Unix has been refined.
>
Didn't he have a :-) after the "well documented vomit" comment? Before
YOU rant and rave about something be sure it is serious!
>Another point you seemed to miss is that the development environment for
>Basic is quite good. You can stop your program, display variables, patch
>the SOURCE CODE, and eliminate long boring compilations. Then when the
>program logic is complete, it can be compiled ONCE and it will run
>pretty damn fast.
>
So? You can get Pascal interpreters and C interpreters and Forth
interpreters ( and probably SmallTalk and Lisp interpreters )
with almost all of these properties ( I don't think there are any
compiled SmallTalks ).
>In 'C', when you see a call like:
>w=opnwndw(xqtnm);
>the only way you can tell what it does is by using grep to find out
>where the function is defined and if you are lucky, it will be documented.
What does this have to do with C?
>
>At least in Basic, all of the keywords are WELL KNOWN,
Are you claiming that the keywords for C are not well known ?!?
> and no two programmers' opnwndw() functions are different (the language
>defines the call),
It does? I have never seen an opnwndw function on any BASIC I have
used!
> and the language (Basic) tends to be geared
>toward using whatever hardware the interpreter is implemented on
>in a easy to use way. Not many implementations of Unix (written
>in 'C') have been ported to machines and really use the hardware
>- READ ON - I have not seen a compiler that will use the string
>functions that the 808x family of processors provide. These
>kinds of instructions (LODS, STOS, etc.) are what makes the
>processor FAST.
Any speed a BASIC interpreter gains from using the string instructions
is probably lost in the overhead of being an interpreter.
--
Tim Smith sdcrdcf!ism780c!tim || ima!ism780!tim || ihnp4!cithep!tim
Scott Dorsey
>>In article <1...@crin.UUCP> tom...@crin.UUCP (Karl Tombre) writes:
>> I am sorry. But any language that does not allow parameter passing
>>has something seriously wrong with it. Even most assemblers give you
>>some 'ram it on the stack and call' stuff.
>
>Who SAYS BASIC doesn't allow parameters?? I GREW UP on Dartmouth BASIC.
>It sure does. Now, this Microswill thing, I dunno...
Dartmouth BASIC isn't a real BASIC. It's almost useful, and is miles
ahead of most microcomputer BASICS. For that matter, so is CBASIC. Still,
you'd have to pay me to use them.
da...@cbmvax.uucp
(real) languages [hey, there he goes again, blatently revealing his bias
in the first sentence]. C, LISP, Pascal, BASIC, etc., all have standard
built-in functions. Some may take advantage of the processor's
capabilities, some may not. However, with BASIC (and to a degree
PASCAL) you have the concept of functions that are an integral part of
the language. If its a real good implementation, you might have most
of your functions written to take advantage of the hardware you're
working with. If not, you're totally out of luck. Languages like C,
LISP, and FORTH easily allow the complete redefinition of primitive
functions to better adjust to the environment (this is done quite often
in C especially, where just about every compiler and standard library
allows you to define the primitive I/O calls as either macros or
functions). With compiled BASIC you are at the complete mercy of
the compiler when it comes to using your built-in functions, if they
are poorly implemented (as with most BASIC compilers), you'll run
slowly. If my C application needs a function to be faster, I can
rewrite it in machine code if I desire, changing nothing else in the
entire program. Same with FORTH. And when it comes to mnemonic
variables and procedures, my OpenWindow(), OpenLibrary(), SetTitleBar(),
etc. calls to a windowing system are perfectly mnemonic; its the fault
of the programmer if he's not using the capabilities of his language
to its fullest, and the fault of the language if he's got to deal with
several sheets of notes reminding him of the difference between
AD, AC, ST, DV, D2, D2, X, XX, Y3, CK$, FT%, FNA, FNB, etc., which is
exactly what I've done in the past when writing major projects in
BASIC.
ihnp4 \
Dave Haynie allegra -- !cbmvax!daveh
seismo /
Walter Bright
In the Datalight C compiler, the string primitives (strcpy(), strlen(),
memcpy(), etc.) are all implemented using the 8088's string instructions.
You are right in that no code generators I know of will ever generate
string instructions, but I don't think you'll find any Basic interpreters
either that will use LODSB, STOSB etc. when confronted with code that
increments through a loop.
P.S. Does your Basic use the XLAT instruction?
Tim Rentsch
> Dartmouth BASIC isn't a real BASIC.
huh? not only is dartmouth basic A real basic, dartmouth basic is
THE real basic. the original basic was done at dartmouth (wasn't
it?) back in the early 1960's.
(not that this makes basic an acceptable language :-)
cheers,
txr
Daniel R. Levy
>C, LISP, Pascal, BASIC, etc., all have standard built-in functions.
C has standard built-in functions????
Gee, that's a new one on me. EVERY function called from C is an external func-
tion, or at least it was when C began. This includes things like write(),
read(), printf(), math functions, etc. There's no such thing as, for example,
a C builtin equivalent to the FORTRAN MAX() or the Basic INPUT which does the
right thing no what the arguments' types are, or where the returned result is
stored. Of course, C has developed a number of "understood" conventions, like
the omnipresence of the write() and read() functions and their calling conven-
tions but they are not necessarily gospel. That is, you could compile a
function which takes the place of read() and link it in:
read()
{
/* This presumes that write() will remain the "standard" version! */
write(2,"Go fly a kite, I don't feel like reading\n",41);
return 0;
}
and sure 'nuff it would get called, at least in a Unix environment, every time
that a program tried to read something through read() or through stdio. (I
tried it.) Try that with any of the Basic builtins!
I do grant that these conventions like read() and write() have become, through
hallowed usage (mostly in Unix) standard enough that some C compilers can get
away with treating them as builtins without breaking any code except that which
tries to redefine these conventions. VAX/VMS C, for instance, will treat a
call of read() as a call of something like C$$READ() while not changing a call
of reed() to a call of C$$REED() in analogy. But that is just cosmetic stuff;
C in essence still behaves as if all functions (following macro expansions)
were external functions, so that (maybe because?) implementations which treat
them that way (e.g., Unix) are still quite valid.
--
------------------------------- Disclaimer: The views contained herein are
| dan levy | yvel nad | my own and are not at all those of my em-
| an engihacker @ | ployer or the administrator of any computer
| at&t computer systems division | upon which I may hack.
| skokie, illinois |
-------------------------------- Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa,
vax135}!ttrdc!levy
Daniel R. Levy
>C, LISP, Pascal, BASIC, etc., all have standard built-in functions.
[O net.lang.c gurus, am I on the mark here? This was originally in net.lang.]
P. D. Guthrie
>In article <4...@cbmvax.cbmvax.cbm.UUCP>, da...@cbmvax.UUCP writes:
>>C, LISP, Pascal, BASIC, etc., all have standard built-in functions.
>
>
>Gee, that's a new one on me. EVERY function called from C is an external func-
>tion, or at least it was when C began.
You are sort of right, but sizeof qualifies as a builtin function,
even though it is a compile-time function vs run-time. Anyone disagree?
--
Paul Guthrie `When the going gets weird,
ihnp4!ihdev!pdg The weird turn pro'
- H. Thompson
Scott Dorsey
>
>> Dartmouth BASIC isn't a real BASIC.
>
>huh? not only is dartmouth basic A real basic, dartmouth basic is
>THE real basic. the original basic was done at dartmouth (wasn't
>it?) back in the early 1960's.
Dartmouth BASIC is compiled FORTRAN. Ok, I know about FOCAL, but
Dartmouth BASIC shares the same philosophy. It was designed as a teaching
language, and teaches the FORTRAN philosophy very well. However, why
anyone would want to learn the FORTRAN philosophy, I don't know.
Dartmouth BASIC was very good for what it was intended to do. And I
would give anything for a MAT statement in Pascal. But the BASICS that
grew out of it were filthy and vile. And what it was intended to do is
no longer needed.
John Owens
> know to write their programs like this from the beginning! (And of course,
> they run a global renumberer every couple minutes!)
>
> other people who wound up avid BASIC-haters precisely because it was the first
> language they learned...
>
> -Colin Kelley ..{psuvax1,pyrnj}!vu-vlsi!colin
>
I seem to have followed almost the same path that you did. I started
out with only 4K of RAM, so I tended to fanatically optimize my programs
for space as well as speed, even to the point of starting with a goto to
the bottom of the program, and having often-used subroutines at the top
of the program, in order of use.... I even restorted to multiple ELSEs
per IF, and all those other horrible things. I found that I could
write relatively bug-free code, as long as I did it all in a short
period of time. If I tried to come back to it later, I couldn't ever
keep straight all the side-effects of things, and had a terrible time.
Nowadays, I use basic for small (less than 20 line) programs, occasionally,
but I shudder at the idea of a large program written in BASIC. (An unnamed
contractor recently wrote a *LARGE* software package in BASIC, and it would
be impossible for anyone else to maintain, even though the author went to
reasonable lengths to keep it structured.)
So I suppose I don't hate BASIC, I just consider it impractical.
--
John Owens
edison!jso%virg...@CSNet-Relay.ARPA
General Electric Company Phone: (804) 978-5726
Factory Automation Products Division Compuserve: 76317,2354
houxm!burl!icase!uvacs
...!{ decvax!mcnc!ncsu!uvacs }!edison!jso
gatech!allegra!uvacs
Joseph S. D. Yao
>C has standard built-in functions????
Well, C has standard (library) functions. C can also have built-in
functions to make it standard-conforming. E.g., on machines which
do not have instructions to handle longs or floats or doubles or some
other standard feature of C (or switch...) the compiler is perfectly
justified in setting up code to call a "built-in" function to do this.
I know ... I had to write an early version of lmul/ldiv/lrem on the
PDP-11, and arrange for FP routines to be trapped to. This is not to
be confused with _lmul(), _fdiv(), or anything like that.
Michael Meissner
>In article <4...@cbmvax.cbmvax.cbm.UUCP>, da...@cbmvax.UUCP writes:
>>
>>C, LISP, Pascal, BASIC, etc., all have standard built-in functions.
>
>C has standard built-in functions????
>
>Gee, that's a new one on me. EVERY function called from C is an external func-
>tion, or at least it was when C began. This includes things like write(),
>read(), printf(), math functions, etc. There's no such thing as, for example,
>a C builtin equivalent to the FORTRAN MAX() or the Basic INPUT which does the
>right thing no what the arguments' types are, or where the returned result is
>stored. ...
That may be the original practice, but the X3J11 (ANSI C) drafts, now quite
clearly say that all functions defined in the library are reserved (ie, you
can't redefine them), and may be builtin to the compiler. I believe that the
/usr/group standard (and probably P1003) reserved every function from all major
UNIX* variants. It may be that redefining these reserved library functions
will continue to work in *YOUR* implementation, but it's not guaranteed.
Michael Meissner, Data General
...{ decvax, ihnp4 }!mcnc!rti-sel!dg_rtp!meissner
*UNIX is a trademark of AT&T in the U.S.A. and other countries.