mykes@3comvax.UUCP (Mike Schwartz) (01/17/86)
I would like to tell you folks about a couple of assembler/compilers
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 strcpycramer@kontron.UUCP (Clayton Cramer) (01/20/86)
> 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). 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). > Mike Schwartz @ 3Com Corp. >
budd@boring.UUCP (01/23/86)
[ I know I'll regret this ] >I would like to tell you folks about a couple of assembler/compilers >I wrote for a real nice structured programming language for the 6502. >First, however, a little background. > ... >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. no death threats; far from it. I think a well defended counter-orthodox opinion is good every now and then for those of us who hold to the conventional beliefs, in order to force us to consider WHY we hold those ideas, and to ask ourselves if we might not be wrong, after all. Therefore, here is my rendering of the conventional arguments. The arguments Mike puts forward seem to concern two ideas, portability and machine resource utilization. I will treat these as two issues in turn. A typical quote on the first issue: >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). Well, there is software and then there is software. The term covers a lot of different things. One difference in software is how close you need to get to the actual machine. For some types of software, i.e. device drivers, it is necessary to be quite close to the real hardware. This type of code is generally not very portable. C allows you to program much of this code in a high level language, but that still doesn't make it portable to different hardware situations. On the other hand, many applications written in C do not need to concern themselves with the hardware much at all. My Little Smalltalk system, for example, is written entirely in C, and runs on about two dozen different machines with no more than a few system calls changed here and there (all nicely handled in one place using #ifdef's). I expect that the kind of applications that Mike is used to, vidio game programming, is closer to the device driver style of programming than to interpreter construction (Little Smalltalk is an interpreter) style of programming. Thus I'm not surprized that he wouldn't think C would add much to portability in this area. I'm inclined to think that even here it would help some (with the proper choice of system call interface), but it certainly isn't going to solve the whole problem. Mike's second point concerns machine resources. >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? Any of my former students on the net who have heard me give my ``The position of Computer Science in the grand scheme of Western Civilization'' lecture will get the feeling they have heard this already. They are right. In fact, I probably do a better job in lecture than I can do here. (particularly since I'm suffering from a cold right now), Nevertheless: I think it is frequently the case that computer science students forget why computer science is important. Basically stated, there are problems that need to be solved, and in many cases the solutions to those problems is greatly facilitated (or even possible at all) only using a computer. Thus the computer is merely a tool used for a larger purpose, namely to solve problems. The difficulty is that problems arise from situations involving people. People tend to view things differently than computers. In particular, people usually conceptualize problems, and in as much as we have any idea HOW people solve problems, they seem to solve problems in a manner different from that used by computers. Thus the fundamental problem in computer science (to my mind), is how to bridge the gap between problem formulation in people-terms, and problem solution in computer-terms. In the previously mentioned lecture I usually go into some detail mentioning how the various fields of computer science can be viewed in this light, which I won't do here, other than to say that there are some obvious consequences for programming language design implied by this attitude. The most obvious observation is that you can push the language design issue in the direction of the computer-terms side of the picture, forcing the user of the language to think more like the computer, or you can push the language in the direction of the people-terms side (in various different ways), and leave it to the language implementor, and not the problem solver to decide how this will eventually get mapped down to the computer level. Admittedly, in the latter case, various inefficiencies necessarily get introduced. But this may be more than offset by the fact that it is easier to think (and program) in a language closer to the one the problem is conceptualized in. Let me toss in another one of Mikes quotes here: >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...). to which the conventional answer might be ``I shudder to think of all the brain cell hours that are needlessly wasted pondering poorly structured programs, tracking down illegal subscript errors or pointers gone wild'' APL programmers (a strange breed of their own) have been telling us for years that the most important measure is the time between a problem definition and the problem solution, and if by using a high level language this time is cut in half (or less) then who cares if in so doing you use 10 times more machine resources. It is people time that is important, not machine time. Again, there is software and there is software. My own personal opinion is that for the VAST majority of what most people program, the argument that people time is more important is the right one, and the language should be a very high level language (not even `C', but more abstract, but that's a different issue altogether that I can lecture on some day if people want). I will ALWAYS admit that there is some software (editors, compilers) for which this isn't true, and for those a language that permits the generation of more ``efficient'' code is preferable. Most people don't write compilers, other than toy ones in college. Well, I've rambled on more than I should have in my physically (and mentally, I assume) weakened state. I close with just one more quote from Mike: >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 quite agree. I'm glad most people don't have to program such applications. As with mike, let me close with a plea for reasoned discussion, and fewer death treats. --tim budd (mcvax!budd) assn't prof, dept of computer science, the university of arizona, on leave at the CWI, amsterdam, the netherlands.
franka@mmintl.UUCP (Frank Adams) (01/28/86)
In article <463@kontron.UUCP> cramer@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
wcs@ho95e.UUCP (x0705) (02/05/86)
In article <1078@mmintl.UUCP> franka@mmintl.UUCP (Frank Adams) writes: > >In article <463@kontron.UUCP> cramer@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. Or their 4.2BSD Communications code to Xenix .... "What's a socket?" >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
mykes@3comvax.UUCP (Mike Schwartz) (02/09/86)
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.macrakis@harvard.UUCP (Stavros Macrakis) (02/10/86)
> ... user-friendliness has become a big issue in the software world ... a > 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@tesla.UUCP (Wrolf Courtney) (02/11/86)
[Go ahead - eat my shield!] In the latest of this saga mykes@3comvax.UUCP (Mike Schwartz) writes in <409@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
schooler@inmet.UUCP (02/11/86)
[I suppose this doesn't really belong in net.lang.]
Saving on programmer time is very important in the commercial world.
If it takes a programmer half as long to build something, then the
product costs half as much (more or less). I agree that it is
sometimes the case that a speed factor can make or break a product,
but I believe that it is more often the case that cost and time to
market are more important.
-- Richard Schooler
Intermetrics, Inc.
{ihnp4,ima}!inmet!schoolerrb@ccivax.UUCP (rex ballard) (02/12/86)
In article <463@kontron.UUCP> cramer@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. 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.
bobc@tikal.UUCP (Bob Campbell) (02/14/86)
Sorry but I have to put in my 2 cents (or given the cost of transmitting this 2 dollars) worth. In article <409@3comvax.UUCP> mykes@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
craig@dcl-cs.UUCP (Craig Wylie) (02/18/86)
-- 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. -- Bob Campbell -- >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: craig@uk.ac.lancs.comp | Bailrigg, Lancaster, UK. Phone: +44 524 65201 Ext. 4146 | LA1 4YR Project: Cosmos Distributed Operating Systems Research Group
doug@terak.UUCP (Doug Pardee) (02/21/86)
[Oh, goody, one of my favorite topics, I think I'll butt in...] > > 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@terak.UUCP (Doug Pardee) (02/21/86)
> 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.
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.
--
Doug Pardee -- CalComp -- {hardy,savax,seismo,decvax,ihnp4}!terak!dougbobc@tikal.UUCP (Bob Campbell) (02/26/86)
<I just can leave this one alone> In article <1053@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.
throopw@dg_rtp.UUCP (Wayne Throop) (02/28/86)
[ My reply below is Humorous in Nature (gasp), perhaps even
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!throopwfranka@mmintl.UUCP (Frank Adams) (03/05/86)
In article <997@dcl-cs.UUCP> craig@comp.lancs.ac.uk (Craig Wylie) writes: >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 Multimate International 52 Oakland Ave North E. Hartford, CT 06108
franka@mmintl.UUCP (Frank Adams) (03/05/86)
In article <1056@terak.UUCP> doug@terak.UUCP (Doug Pardee) writes: >> 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 Multimate International 52 Oakland Ave North E. Hartford, CT 06108
craig@dcl-cs.UUCP (03/08/86)
..... me (Craig) rambling on about shell as a fast prototyping language ... >> >>Shell is also both polymorphic and functional (using evaluation quotes), >>sounds pretty good to me. In article <1165@mmintl.UUCP> franka@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 (mb@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). Craig. -- UUCP: ...!seismo!mcvax!ukc!dcl-cs!craig| Post: University of Lancaster, DARPA: craig%lancs.comp@ucl-cs | Department of Computing, JANET: craig@uk.ac.lancs.comp | Bailrigg, Lancaster, UK. Phone: +44 524 65201 Ext. 4146 | LA1 4YR Project: Cosmos Distributed Operating Systems Research Group
mykes@3comvax.UUCP (Mike Schwartz) (03/10/86)
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.
david@ztivax.UUCP (03/18/86)
NO NO NO!! PLEASE NOT BASIC!! 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
tombre@crin.UUCP (Karl Tombre) (03/20/86)
In article <7900003@ztivax.UUCP> david@ztivax.UUCP writes: >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.
kludge@gitpyr.UUCP (Scott Dorsey) (03/22/86)
In article <153@crin.UUCP> tombre@crin.UUCP (Karl Tombre) writes: >In article <7900003@ztivax.UUCP> david@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
tohaapanen@watrose.UUCP (Tom Haapanen) (03/26/86)
tombre@crin.UUCP (Karl Tombre) writes: >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@celtics.UUCP (Roger Klorese) (03/26/86)
>In article <153@crin.UUCP> tombre@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... (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!roger@harvard.ARPA, celerity!celtics!roger@sdcsvax.ARPA
kayvan@ucbvax.BERKELEY.EDU (Kayvan Aghaiepour) (03/27/86)
In article <7900003@ztivax.UUCP> david@ztivax.UUCP writes: > >Real men use 4th generation languages... > >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
mykes@3comvax.UUCP (Mike Schwartz) (03/28/86)
In article <7947@watrose.UUCP> tohaapanen@watrose.UUCP (Tom Haapanen) writes: >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. 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"
asente@cascade.ARPA (Paul Asente) (03/28/86)
In article <7947@watrose.UUCP> tohaapanen@watrose.UUCP (Tom Haapanen) writes: >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. ... >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 asente@cascade.ARPA decwrl!glacier!cascade!asente
tim@ism780c.UUCP (Tim Smith) (04/01/86)
In article <463@3comvax.UUCP> mykes@3comvax.UUCP (Mike Schwartz) writes: >In article <7947@watrose.UUCP> tohaapanen@watrose.UUCP (Tom Haapanen) writes: >>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
kludge@gitpyr.UUCP (Scott Dorsey) (04/02/86)
In article <995@celtics.UUCP> roger@celtics.UUCP (Roger Klorese) writes: >>In article <153@crin.UUCP> tombre@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. -- ------- 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
daveh@cbmvax.UUCP (04/02/86)
I'd like to add a few words on the subject of BASIC versus other
(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 /bright@dataioDataio.UUCP (Walter Bright) (04/03/86)
In article <463@3comvax.UUCP> mykes@3comvax.UUCP (Mike Schwartz) writes: > 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. 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?
rentsch@unc.UUCP (Tim Rentsch) (04/06/86)
In article <1603@gitpyr.UUCP> kludge@gitpyr.UUCP (Scott Dorsey) writes: > 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
levy@ttrdc.UUCP (Daniel R. Levy) (04/06/86)
In article <41@cbmvax.cbmvax.cbm.UUCP>, daveh@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. 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
levy@ttrdc.UUCP (Daniel R. Levy) (04/06/86)
In article <41@cbmvax.cbmvax.cbm.UUCP>, daveh@cbmvax.UUCP writes: >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.] 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
pdg@ihdev.UUCP (P. D. Guthrie) (04/06/86)
In article <824@ttrdc.UUCP> levy@ttrdc.UUCP (Daniel R. Levy) writes: >In article <41@cbmvax.cbmvax.cbm.UUCP>, daveh@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. 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
kludge@gitpyr.UUCP (Scott Dorsey) (04/07/86)
In article <1209@unc.unc.UUCP> rentsch@unc.UUCP (Tim Rentsch) writes: > >> 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. -- ------- 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
jsdy@hadron.UUCP (Joseph S. D. Yao) (04/08/86)
In article <824@ttrdc.UUCP> levy@ttrdc.UUCP (Daniel R. Levy) writes: >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.
meissner@dg_rtp.UUCP (Michael Meissner) (04/08/86)
In article <824@ttrdc.UUCP> levy@ttrdc.UUCP (Daniel R. Levy) writes: >In article <41@cbmvax.cbmvax.cbm.UUCP>, daveh@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.
eric@chronon.UUCP (Eric Black) (04/09/86)
In article <824@ttrdc.UUCP> levy@ttrdc.UUCP (Daniel R. Levy) writes: >In article <41@cbmvax.cbmvax.cbm.UUCP>, daveh@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. Well, how about sizeof(foo)? It looks like a function invocation, and is known and understood by the compiler... All right, all right, K & R calls it an "operator", but none of us here are known to pick nits, are we?? :-) -- Eric Black "Garbage In, Gospel Out" UUCP: {sun,pyramid,hplabs,amdcad}!chronon!eric
gwyn@brl-smoke.ARPA (Doug Gwyn ) (04/10/86)
In article <202@chronon.UUCP> eric@chronon.UUCP (Eric Black) writes: >Well, how about sizeof(foo)? > >It looks like a function invocation, and is known and understood >by the compiler... Rong. "sizeof" comes in two flavors: sizeof <type-cast> sizeof <object> In the first case, the parentheses belong to the <type-cast>, not to the sizeof syntax; in the second case, surrounding the <object> with parentheses is not usually necessary: int array[20]; ... sizeof array ...
arnold@ucsfcgl.UUCP (Ken Arnold%CGL) (04/10/86)
In article <202@chronon.UUCP> Eric Black writes: >Well, how about sizeof(foo)? > >It looks like a function invocation, and is known and understood >by the compiler... > >All right, all right, K & R calls it an "operator", but none of >us here are known to pick nits, are we?? :-) Not really. If "foo" is a variable, you can just as well say "sizeof foo". You only need the parentheses if "foo" is a type name, e.g., "int". I almost never use "sizeof (type)" since then I have to know which type the variable I am associating it with has. Er, let me try phrasing that in code. some_type *ptr; ptr = malloc(10 * sizeof *ptr); is better (to me) then ptr = malloc(10 * sizeof (some_type)); because it is more true. In the first case I get exactly what I want, in the second I have no guarantee that the size I'm using relates in any way to the type of "ptr". If write the first way, and then change the type of "ptr" to "some_other_type *ptr", life. Purists will note that I really should say ptr = (some_type *) malloc(10 * sizeof *ptr); But eventually malloc() will be of type "void *". This is also an argument for a new "typeof" operator. I presume, however, that ANSI has continued to ignore this, so I guess we're stuck. I'd be glad to be disabused of this notion if someone who has access to the latest draft would tell me. It sure would be nice to look at it sometime before it is officially a proposed standard. Ken Arnold P.S. Another place many people use unecessary parentheses is with "return". About 80% of the people I talk with don't even know they aren't required.
ken@rochester.ARPA (Ipse dixit) (04/11/86)
In article <202@chronon.UUCP> eric@chronon.UUCP (Eric Black) writes: >Well, how about sizeof(foo)? > >It looks like a function invocation, and is known and understood >by the compiler... Ah, but it can be written without the parentheses, i.e. sizeof foo, except when foo is a type, so most people parenthesize it anyway, and don't bother to remember when to and when not to. Ken -- UUCP: ..!{allegra,decvax,seismo}!rochester!ken ARPA: ken@rochester.arpa Snail: CS Dept., U. of Roch., NY 14627. Voice: Ken!
pasm@pur-ee.UUCP (PASM Parallel Processing Laboratory) (04/11/86)
>>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. > >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? Yep, I disagree: sizeof is an OPERATOR. See K&R p. 49. You might write something like: sizeof(int) which LOOKS like a function call to the uninitiated, but you can just as correctly write: sizeof int What the heck is a compile-time function? Real useful - functions that return constants. Come on now. (Jim Kuehn; kuehn@ed.purdue.edu; ...ihnp4!pur-ee!kuehn) --jk
kwh@bentley.UUCP (KW Heuer) (04/11/86)
In article <584@ihdev.UUCP> ihdev!pdg (P. D. Guthrie) writes: >... but sizeof qualifies as a builtin function, even though it is a >compile-time function vs run-time. Anyone disagree? Yes, I disagree. The only thing "sizeof" has in common with a "function" (in the C sense) is that it is often written with the argument enclosed in parentheses. (Not always; I've seen "sizeof foo" many times.) It is a function in the mathematical sense, with a domain of "datatype" (though it can also take an expression, which is essentially cast into "datatype"), but I don't think that's what we're talking about here. Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint
jss@ulysses.UUCP (Jerry Schwarz) (04/11/86)
> 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? It is not a function at all. It is a language construct that syntactically is an operator but sematically is not a function. In the form "sizeof expr" C does not evaluate what appears to be an argument. And in the form "sizeof(type-name)" what appears to be an argument does not have a value.
henry@utzoo.UUCP (Henry Spencer) (04/11/86)
> ... but sizeof qualifies as a builtin function, > even though it is a compile-time function vs run-time. Anyone disagree? Fraid so. Sizeof is an *operator*, which can (but does not have to be) invoked with a function-like syntax. If foo is a variable, "sizeof foo" (note no parentheses) is legitimate. The parentheses are necessary for syntactic reasons when the operand of sizeof is a type -- and if you think this is easy to parse, you should try it sometime! -- but they do not make sizeof a function. -- Support the International League For The Derision Of User-Friendliness! Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,decvax,pyramid}!utzoo!henry
ka@hropus.UUCP (Kenneth Almquist) (04/12/86)
> 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? The sizeof operator doesn't use the function call syntax; it is legal to write "sizeof i" rather than "sizeof(i)". Of course, in the case of "sizeof(int)" the parenthesis are necessary, but since "int" is a reserved word this still doesn't look quite like a function call. Kenneth Almquist ihnp4!houxm!hropus!ka (official name) ihnp4!opus!ka (shorter path)
pdg@ihdev.UUCP (P. D. Guthrie) (04/14/86)
In article <6584@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >> ... but sizeof qualifies as a builtin function, >> even though it is a compile-time function vs run-time. Anyone disagree? > >Fraid so. Sizeof is an *operator*, which can (but does not have to be) >invoked with a function-like syntax. If foo is a variable, "sizeof foo" >(note no parentheses) is legitimate. The parentheses are necessary for >syntactic reasons when the operand of sizeof is a type -- and if you >think this is easy to parse, you should try it sometime! -- but they >do not make sizeof a function. >-- I admit that you are quite correct. Infact when I decided to look this up in the gospel according to K&R, in the index it is listed under 'sizeof operator'. I was thinking of it as a function in a more mathematical (rather than syntactical) sense, but I guess all operators can qualify there (eg. unary minus f(x) = -(x)). I don't know, but I still think that the domain and range of sizeof makes it fit better with functions than operators, but the distinction here is getting murkey. >Support the International League For The Derision Of User-Friendliness! Actually, this is not such a bad idea. There are many times when user friendlyness is a curse. A good example is programs that require a basis of knowledge about the principles used (for instance object-code editors) to do anything. In this example, it is not good to make it easy to modify object code as it encourages this sort of thing. In general, certain actions that should be done with care should not be made simple for anyone to do. This time I won't ask if anyone disagrees as I am sure many people will, but as always thoughtful followups are encouraged, but net.lang is probably not the correct place. > > Henry Spencer @ U of Toronto Zoology > {allegra,ihnp4,decvax,pyramid}!utzoo!henry -- Paul Guthrie `When the going gets weird, ihnp4!ihdev!pdg The weird turn pro' - H. Thompson
levy@ttrdc.UUCP (Daniel R. Levy) (04/16/86)
Looks like I've started a minor ruckus here in net.lang[.c]. The consensus (other than all the quibbling about sizeof) seems to be that C may, but needn't, implement the "standard" functions as wholly external (and thus user-replaceable) in today's world. My original comments to the effect that all C functions are external reflect my impression of the K and R approach to the matter (The comment is very near the front of the book, and specifically makes a point about the I/O functions.) I think that inline expansion would make lots of sense for cases like printf() (which as an external function call must interpret its format at run time when used with a fixed format string). In this case, it could be treated much as Fortran treats formatted I/O statements, parsing the formats at compile time. (Or at least highly efficient For- trans, such as VMS's, do this; a side benefit is that format errors are detected at compile time, catching things like using an integer format to print out a double precision variable, etc. In the case of C, this kind of treatment could catch this kind of error and others which are peculiar to printf and its kin, such as too few or too many arguments after the format.) Someone commented (either on the net or to me) that hosted C language implementations were expected to have an external set of the "standard" functions on hand even if they were treated differently when invoked inline. This kind of makes sense, since C lets a user pass a pointer to a function to another function which is allowed to invoke it by pointer, and it might be desireable to use a "standard" function in that way, e.g., passing strcmp() as a comparison routine to a general purpose searching or sorting routine a la qsort(). Are there other reasons? (Far be it from me to fuel further debate :-) ). -- ------------------------------- 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
jsdy@hadron.UUCP (Joseph S. D. Yao) (04/17/86)
In article <6584@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >[unattributed] >> ... but sizeof qualifies as a builtin function, >> even though it is a compile-time function vs run-time. Anyone disagree? >Fraid so. Sizeof is an *operator*, which can (but does not have to be) >invoked with a function-like syntax. ... Any operator which maps its args into a unique value in its range defines an operation which is a function. Just because you can say a + b doesn't mean that (plus a b) [resp., plus(a, b)] is not a function. Similarly, sizeof(i), whether or not you use parens (and I always do) is an operator which, of course, is a function. Were you talking about details of implementation, perhaps? -- Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}
jj@nrcvax.UUCP (04/19/86)
In article <584@ihdev.UUCP> pdg@ihdev.UUCP (55224-P. D. Guthrie) writes: > >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 'Sizeof' does not have to look like a function at all. Think of it as a multi-character operator. It seems to be convention to always use 'sizeof(x)' when 'sizeof x' would work the same. The parenthesis are only necessary when 'x' is a type. I guess this is the same as most people using 'return (x)' instead of just 'return x'. -- ------------------------------------------------------------------------- Jeff Jennings Network Research Corp. ihnp4!nrcvax!jj 923 Executive Park Drive Suite C ucbvax!calma!nrcvax!jj Salt Lake City, Utah 84117, U.S.A. {sdcsvax,hplabs}!sdcrdcf!psivax!nrcvax!jj (801) 266-9194
bzs@bu-cs.UUCP (04/20/86)
> What the heck is a compile-time function? Real useful - > functions that return constants. Come on now. Whaddya mean? Macros provide compile time functions. I once wrote a macro in ibm/asmh which yielded the sqrt of it's argument in-line, another which ate lisp-like code and turned it into assembler at 'compile' time. Some constants are useful. Probably depends on your pre-processor whether you have this view. -Barry Shein, Boston University
jso@edison.UUCP (John Owens) (04/24/86)
> 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 Yes. Try this on your favorite C compiler and tell me if you still think that "sizeof" is a function as opposed to an operator. main() { int a; printf("%d\n",sizeof a); /* note no parentheses */ } John Owens @ General Electric Company (+1 804 978 5726) edison!jso%virginia@CSNet-Relay.ARPA [old arpa] edison!jso@virginia.EDU [w/ nameservers] jso@edison.UUCP [w/ uucp domains] {cbosgd allegra ncsu xanth}!uvacs!edison!jso [roll your own]
ark@alice.UucP (Andrew Koenig) (04/24/86)
> Any operator which maps its args into a unique value in its range > defines an operation which is a function. Just because you can > say a + b doesn't mean that (plus a b) [resp., plus(a, b)] is not > a function. Similarly, sizeof(i), whether or not you use parens > (and I always do) is an operator which, of course, is a function. > Were you talking about details of implementation, perhaps? The C definition of "function" is not the same as the mathematical definition. A C function is a part of a program. A mathematical function is a set of ordered pairs that meet certain conditions. That said, note that sizeof(i) is syntactically a constant. This would not be true if sizeof were a function.
jso@edison (04/25/86)
Subject: Re: Re: structured assembler (BASIC) [Really: C builtin functions?] > 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 Yes. Try this on your favorite C compiler and tell me if you still think that "sizeof" is a function as opposed to an operator. main() { int a; printf("%d\n",sizeof a); /* note no parentheses */ } John Owens @ General Electric Company (+1 804 978 5726) edison!jso%virginia@CSNet-Relay.ARPA [old arpa] edison!jso@virginia.EDU [w/ nameservers] jso@edison.UUCP [w/ uucp domains] {cbosgd allegra ncsu xanth}!uvacs!edison!jso [roll your own]
ark@alice (04/25/86)
Subject: Re: structured assembler (BASIC) [Really: C builtin functions?] > Any operator which maps its args into a unique value in its range > defines an operation which is a function. Just because you can > say a + b doesn't mean that (plus a b) [resp., plus(a, b)] is not > a function. Similarly, sizeof(i), whether or not you use parens > (and I always do) is an operator which, of course, is a function. > Were you talking about details of implementation, perhaps? The C definition of "function" is not the same as the mathematical definition. A C function is a part of a program. A mathematical function is a set of ordered pairs that meet certain conditions. That said, note that sizeof(i) is syntactically a constant. This would not be true if sizeof were a function.
greg@utcsri.UUCP (Gregory Smith) (04/27/86)
In article <375@hadron.UUCP> jsdy@hadron.UUCP (Joseph S. D. Yao) writes: >In article <6584@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >>[unattributed] >>> ... but sizeof qualifies as a builtin function, >>> even though it is a compile-time function vs run-time. Anyone disagree? >>Fraid so. Sizeof is an *operator*, which can (but does not have to be) >>invoked with a function-like syntax. ... > >Any operator which maps its args into a unique value in its range >defines an operation which is a function. Just because you can >say a + b doesn't mean that (plus a b) [resp., plus(a, b)] is not >a function. Similarly, sizeof(i), whether or not you use parens >(and I always do) is an operator which, of course, is a function. sizeof is NOT a C function ( 'function' is used in the C language sense and not in the mathematical sense ). Operators and functions are distinct in terms of the language definition. Consider the following ( the first two have been posted many times; I have not seen the third one yet ). (1) `sizeof( int * )' is obviously not a function call, but is valid. (2) `sizeof foo' is not a function call, but is valid. (3) `sizeof(foo)' looks like a function call, but is _used_to_obtain_ _symbol_table_information_that_is_not_necessarily_available_at_run_ _time_. It would not be possible to write a run-time function in C or assembler that would act in the same way that sizeof does. E.g. an 'int' would be passed whether 'foo' was 'int' or 'char', so even if you had the ability to measure the size of the parameter block, which is not often the case, it couldn't be done. So enough already ! ! ! ! ! ! ! ! Incidentally, in this sense, a+b is very different from a function. `a+b' does many different things depending on the types of a and b. (a=float, b=int; a=char,b=long etc) A C-callable function of the form plus(a,b) would obviously not do this. Another point: C functions don't even map their args into a unique value. consider getc(f) in the case where f is always the run-time constant 'stdin'. -- "For every action there is an equal and opposite malfunction" ---------------------------------------------------------------------- Greg Smith University of Toronto UUCP: ..utzoo!utcsri!greg
franka@mmintl.UUCP (Frank Adams) (05/01/86)
In article <5341@alice.uUCp> ark@alice.UUCP writes: >The C definition of "function" is not the same as the mathematical >definition. A C function is a part of a program. A mathematical >function is a set of ordered pairs that meet certain conditions. > >That said, note that sizeof(i) is syntactically a constant. This >would not be true if sizeof were a function. Good grief! I am getting very tired of this. You can think of sizeof as a function if you want to, and you can think of it as not being a function if you want to. For some purposes (I haven't noticed any purpose in the discussion so far) one is more useful; for others, the other is. Now will everybody please SHUT UP about the subject? Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Multimate International 52 Oakland Ave North E. Hartford, CT 06108