osmith@acorn.co.uk (Owen Smith) (02/12/91)
In article <1991Feb11.105227.15182@and.cs.liv.ac.uk> rkl@and.cs.liv.ac.uk writes: >I was dabbling in C on our HP UNIX boxes a while back and I was shocked at >the complete lack of warning about the following: > >hello(param1,param2) >int param1,param2; >{ > printf("Param 2 = %d\n",param2); >} > >main() >{ > hello(1); >} Your compiler did the "correct" thing. The definition of the function hello() merely acts as a declaration of hello(); since you have used a traditional C definition. Thus when you make the hello(1) call, everything looks fine to the compiler. It has no idea how many parameters hello() has or what type they should be. The fact that the function definition is in the same file makes no difference whatsoever. Indeed I would be worried if your compiler did give a warning as that would imply it was non-standard and may well cause porting problems. If you had instead written void hello ( int param1, int param2 ) { printf("Param 2 = %d\n", param2); } then in this case you would have got a warning, since an ANSI style function definition also acts as a declaration of the function with the appropriate function prototype: void hello ( int param1, int param2 ); You must remember the difference between a DEFINITION and a DECLARATION when you are programming in C. One of the things that BASIC lacks altogether is declarations. Owen (a C programmer, lost in the wilderness) The views expressed are my own and are not necessarily those of Acorn.
mathew@mantis.co.uk (mathew) (02/12/91)
rkl@and.cs.liv.ac.uk (Richard K Lloyd) writes: >In article <1991Feb10.180855.17062@cns.umist.ac.uk>, >rogersh%t1a@uk.ac.man.cs writes: >> Pascal & C are block structured, BASIC isn't. > >Hmmm...a slightly rash statement there. Of the three, I'd say that >Pascal was the *most* structured, BASIC second and C last of all... Come off it. BASIC doesn't even have proper block structuring for variable scopes. >> and the fact >> that the language of *choice* in almost all commercial systems >> software is C. > >Ahem. It's COBOL and FORTRAN actually...sorry to disappoint you there. He said commercial SYSTEMS software. Little commercial systems software is written in FORTRAN, and almost none in COBOL. FORTRAN is restricted almost exclusively to scientific software, and COBOL is used almost exclusively for business data processing. >Really good Pascals (i.e. Borland's Turbo and VAX/VMS Pascal) give C more >than a run for its money for advanced users. It's the lousier Pascals >(UCSD et al) that give the language a bad name. That's because these "lousy" Pascals are ones which stick to the standard, whereas things like Borland Turbo "Pascal" are so extended as to be Pascal in name only. This, of course, means that you have zero portability from Turbo "Pascal" to anything else. >I was dabbling in C on our HP UNIX boxes a while back and I was shocked at >the complete lack of warning about the following: > >hello(param1,param2) >int param1,param2; >{ > printf("Param 2 = %d\n",param2); >} > >main() >{ > hello(1); >} > >Yes folks, I forgot a parameter and THERE WAS NOT EVEN A WARNING FROM THE >COMPILER! Congratulations. You've realized why nobody makes non-ANSI compilers any more. Have a peanut. >I put it through lint too and NO WARNING AGAIN! I'm suspicious of this; lint ought to be able to notice things like that. I've heard some very nasty comments about HP compilers, so I suspect that you're being misled. >> Dodgy - in a library ok - *not* in the language thanks. The >> great advantage of C is it's *lack* of built in rubbish. All the i/o >> etc. is in standard libraries, reducing the load image size of programs >> which don't need (or want) a pile of utility functions linked in. > >And then you get DUMB linkers that include ALL the routines in the library >that you've specified on the command line, even through you may use only a >few (or even NONE !) in the program :-( Better than linking in all the libraries though, isn't it? That's what dumb Pascal linkers do. >> Absolute not true - compiled BASIC is only a tenth the speed of >> efficiently written compiled C, and 1/12 that of raw ARM code. > >I wish that Hearsay was written in BASIC instead of C...it might be quicker >than a dead (mutant ?) turtle then :-) One thing omitted from the argument >is the fact that a "Hello World" program in C for the Archimedes can turn >out to be big (30 K ?) *and* you need the Shared C library (60K). The >equivalent BASIC program ? About 30 bytes :-) :-) The BASIC interpreter for the Archimedes takes up 30 bytes? I'm impressed. >Richard K. Lloyd, >Computer Science Dept. I don't wish to be unnecessarily insulting, but what are you doing in the computer science department? Did you just drop in on your way to the Arts Faculty? mathew.
csuwr@warwick.ac.uk (Derek Hunter) (02/13/91)
My penn'orth is this: Currently, I only have BASIC on the Arc, so I am rather limited in what I can use (Until my C compiler is finished. I don't waste money on commercial things... :-). I have written a records system for BASIC (I, II, III, IV & V, takes ~1K I seem to remember) /in/ BASIC, so I'm essentially writing my compiler in a very messy Pascal type thing. (I may post the records library if people want it. Uncoded since it's only ~1K and I don't intend to line Pilling's pocket) On UNIX, I write short, very quick, messy and one-shot things in Pascal since BASIC isn't on it, and it would only be Microsoft anyway. For big things, I much prefer C. (t's why I want a version for the Arc - A handy 3rd year project). Since I have to adapt in my programming from tape Beebs up to UNIX, I have no really strong feelings because I don't usually have a choice, but if I were forced to make a decision, I would say BASIC V comes joint with Pascal (Better if they had inbuilt records, and decent file and string handling respectively), and first ANSI C with a darn intelligent linker, and stdio, math, strings,and malloc built into the compiler as extensions producing inline coding. I do feel that massive 'Hello world' binaries is silly, but then you'll only /ever/ really write /one/ of those, won't you? Anyway any halfway decent compiler should spot the disuse of int main(argc, argv, env) sort of 'extras', and not 'include' them. One question, does the Arc's C compiler have a math.h, and does this make it jump to subroutines, or are the FP codes assembled like any other things? - Derek . . . The man with no .sig (I've seen the problems...) - Derek . . . The man with no .sig (I've seen the problems...) - Derek . . . The man with no .sig (I've seen the problems...) [snigger]
asmith@acorn.co.uk (Andy Smith) (02/13/91)
In article <VBD0w17w163w@mantis.co.uk> mathew@mantis.co.uk (mathew) writes: >rkl@and.cs.liv.ac.uk (Richard K Lloyd) writes: >> >>Ahem. It's COBOL and FORTRAN actually...sorry to disappoint you there. > >He said commercial SYSTEMS software. Little commercial systems software is >written in FORTRAN, and almost none in COBOL. FORTRAN is restricted almost >exclusively to scientific software, and COBOL is used almost exclusively >for business data processing. You mean these aren't commercial systems?? >>Really good Pascals (i.e. Borland's Turbo and VAX/VMS Pascal) give C more >>than a run for its money for advanced users. It's the lousier Pascals >>(UCSD et al) that give the language a bad name. > >That's because these "lousy" Pascals are ones which stick to the standard, >whereas things like Borland Turbo "Pascal" are so extended as to be Pascal in >name only. This, of course, means that you have zero portability from Turbo >"Pascal" to anything else. Same with BBC BASIC, its only BASIC by name, but look how many companies have now copied it. You can get BBC BASIC for PC's, Atari, Amiga, etc. There must be something good about BBC BASIC, otherwise why would so many people want to use it. As far as micros go, they all get supplied with a BASIC as standard. I do not know of a machine that get C or Pascal as standard?? >The BASIC interpreter for the Archimedes takes up 30 bytes? I'm impressed. The interpreter is in ROM, therefore it does not take any RAM from the user, you only have to take into account the tokenized form of the program, and its workspace. Andy
cs9h9tts@cybaswan.UUCP (t.simpson) (02/13/91)
In article <VBD0w17w163w@mantis.co.uk> mathew@mantis.co.uk (mathew) writes: >rkl@and.cs.liv.ac.uk (Richard K Lloyd) writes: >>In article <1991Feb10.180855.17062@cns.umist.ac.uk>, >>rogersh%t1a@uk.ac.man.cs writes: >> >>hello(param1,param2) >>int param1,param2; >>{ >> printf("Param 2 = %d\n",param2); >>} >> >>main() >>{ >> hello(1); >>} >> >>Yes folks, I forgot a parameter and THERE WAS NOT EVEN A WARNING FROM THE >>COMPILER! > >Congratulations. You've realized why nobody makes non-ANSI compilers any >more. Have a peanut. > >>I put it through lint too and NO WARNING AGAIN! > >I'm suspicious of this; lint ought to be able to notice things like that. I've >heard some very nasty comments about HP compilers, so I suspect that you're >being misled. I have this funny feeling that Rich was using small-lint (slint) and not lint, all slint does (i think) is to count brackets etc. >>>>is the fact that a "Hello World" program in C for the Archimedes can turn >>out to be big (30 K ?) *and* you need the Shared C library (60K). The >>equivalent BASIC program ? About 30 bytes :-) :-) > I've gotto admit, I do dislike the memory in-efficiency of C. > Tom Simpson : cs9h9tts@uk.ac.swan.pyr
macduff@cbnewse.att.com (Roger R. Espinosa) (02/13/91)
In article <5129@acorn.co.uk>, asmith@acorn.co.uk (Andy Smith) writes: > > In article <VBD0w17w163w@mantis.co.uk> mathew@mantis.co.uk (mathew) writes: > > >rkl@and.cs.liv.ac.uk (Richard K Lloyd) writes: > >> [ COBOL and FORTRAN stuff deleted. Don't even know why it's here... ] > > >>Really good Pascals (i.e. Borland's Turbo and VAX/VMS Pascal) give C more > >>than a run for its money for advanced users. It's the lousier Pascals > >>(UCSD et al) that give the language a bad name. > > > >That's because these "lousy" Pascals are ones which stick to the standard, > >whereas things like Borland Turbo "Pascal" are so extended as to be Pascal in > >name only. This, of course, means that you have zero portability from Turbo > >"Pascal" to anything else. > > Same with BBC BASIC, its only BASIC by name, but look how many companies > have now copied it. You can get BBC BASIC for PC's, Atari, Amiga, etc. There > must be something good about BBC BASIC, otherwise why would so many people > want to use it. As far as micros go, they all get supplied with a BASIC as > standard. I do not know of a machine that get C or Pascal as standard?? Well, no, but the Acorn is the first machine I've seen that has a decent BASIC as standard. GW-BASIC isn't so great (or there wouldn't be QuickBASIC), and I never heard *anything* good about AmigaBASIC when I frequented that part of the net. And yes, it's the same as TurboPascal. My previous knowledge of BASIC (heck, we're talking Applesoft here) does *not* help at all with BBC BASIC. I'm talking about the advanced features necessary to do advanced programming. *I* do like BBC BASIC, I'll admit that. I never thought I'd see the day come when I'd go back to using BASIC, but as a fast prototyping tool, it's beginning to show a lot of merit. What I *don't* understand is why these discussions get started anyway. C is my favorite language to use; this doesn't mean it's the best, or that there aren't any other languages out there better than C. I woudln't mind trying C++, or Smalltalk, or dabbling more in Lisp. Right now, for *me*, C is the better choice, because I can use it on more platforms that I work on (can't say that about Pascal or BASIC or Lisp or Smalltalk). There's never been one standard language, and I hope there never is. What I'd more like to see is a standard means of translating filetypes/filesystems; that would seem more useful a cause than this language-argument business. The current arguments are all deja-vu (to me). It's the "Should we write the tool in sh/awk/sed, or write it in C" discussion I've become so familiar with here on the job. And the answer is always: it depends. Sounds pretty applicable here, too. But I could be wrong (or ignored). Oh well. Roger rre@ihlpm.ATT.COM
gvr@cs.brown.edu (George V. Reilly) (02/14/91)
Does anyone know of a portable PD implementation of BBC BASIC, preferably written in C? Just curious and nostalgic. ________________ George V. Reilly `Syzygy' gvr@cs.brown.edu +1 (401) 863-7684 uunet!brunix!gvr gvr@browncs.bitnet Box 1910, Brown U, Prov, RI 02912
john@acorn.co.uk (John Bowler) (02/14/91)
In article <1991Feb12.233654.5140@warwick.ac.uk> csuwr@warwick.ac.uk (Derek Hunter) writes: >Since I have to adapt in my programming from tape Beebs up to UNIX, I have > no really strong feelings because I don't usually have a choice, but if I > were forced to make a decision, I would say BASIC V comes joint with Pascal > (Better if they had inbuilt records, and decent file and string handling > respectively), and first ANSI C with a darn intelligent linker, and stdio, > math, strings,and malloc built into the compiler as extensions producing > inline coding. With the exception of mathematical operations which correspond to the FP instruction set inlining doesn't seem to help very much on the ARM2 - particularly with stdio and malloc (where the saving of a BL/MOVS PC,LR instruction pair is trivial compared to the overhead in the operations. [Even fgetc needs 11 instructions, including 2 LDR, one STM and one LDM; about 25S cycles (equivalent) compared to 8 for the function call overhead, and it *does* use all the APCS function call registers. The RISC iX malloc has about 20 instructions, 44 S cycles. Both functions are (effectively) hand optimised assembler.] With an ARM3 in-lining is likely to be disadvantageous - code size will increase significantly in some program inner loops and this will descrease overall performance because the in-line code effectively flushes the cache. [It is difficult to arrive at hard figures for this.] String function in-lining has been used by some manufactures to get good dhrystone ratings but the only obvious advantage on the ARM would come from converting strcpy of string constants into memcpy or LDM/STM (depending on string length); even here the small gains hardly seem worth while. Effectively this is just a work-round for the absence of support in C for array assignment. [Note that it has never been particularly clear how best to do structure assignment on the ARM. LDM/STM versus out-of-line calls to versions of memcpy - code size/execution speed questions again; ANSI C release 3 seems to use in-line code at the moment, in the case I tried this cost 4 extra in-line instructions]. Even in-lining DIV and MOD (/ and %) is not done; currently RISC iX uses out-of-line loop unrolled functions, which would be very expensive to in-line. I beleive C/RISCOS_Lib uses the same technique but with less unrolling (on the basis that this is likely to be better on ARM3). > >One question, does the Arc's C compiler have a math.h, and does this make it > jump to subroutines, or are the FP codes assembled like any other things? Math functions are the clear exception; where they correspond to an FP code the compiler can take advantage of not having the APCS floating point caller save registers trashed. Since most FP ops involve only two registers (in practice) this releases two fp registers for use as temporaries. Anyway, all the out-of-line function would do is execute the FP op-code. Unfortunately most ANSI-C math interfaces do *not* correspond to FP op-codes, because they require errno to be set. In-lining the tests of FP status and changes to errno is more difficult, currently the compiler only supports in-lining of sin(), cos(), atan() and fabs() [the out-of-line implementation of the latter, incidentally, can avoid FP operations by doing the operation itself - more efficient even with a hardware coprocessor with the existing APCS]. This in-lining is switched on (if desired) inside math.h. The FORTRAN compiler on the other hand is capable of in-lining far more math functions - FORTRAN programs do not expect errno to be updated! The result is that some mathematical programs may compile to more efficient code when written in FORTRAN. John Bowler (jbowler@acorn.co.uk)
mathew@mantis.co.uk (mathew) (02/16/91)
asmith@acorn.co.uk (Andy Smith) writes: > In article <VBD0w17w163w@mantis.co.uk> mathew@mantis.co.uk (mathew) writes: > >He said commercial SYSTEMS software. Little commercial systems software is > >written in FORTRAN, and almost none in COBOL. FORTRAN is restricted almost > >exclusively to scientific software, and COBOL is used almost exclusively > >for business data processing. > > You mean these aren't commercial systems?? (*sigh*) Please learn the difference between commercial software systems and commercial systems software. > Same with BBC BASIC, its only BASIC by name, but look how many companies > have now copied it. You can get BBC BASIC for PC's, Atari, Amiga, etc. There > must be something good about BBC BASIC, otherwise why would so many people > want to use it. Certainly if you want a BASIC, BBC BASIC is probably the least bad of a lousy bunch. > As far as micros go, they all get supplied with a BASIC as > standard. I do not know of a machine that get C or Pascal as standard?? The Atari ST was originally supplied with Logo as a standard language. In a typical Atari backwards move, they stopped bundling it after a couple of years. The Jupiter Ace was supplied with Forth as its standard language. The Macintosh is supplied with Hypertalk as a standard language. Every single UNIX machine gets C as the standard language, and many get Pascal, C++, or Lisp as well. To digress a little, it seems to me that there is quite a shocking level of ignorance in this newsgroup. One of the things which annoyed me about BBC Micro owners (at the time when I *was* one) was the way in which they shut themselves away in their own little clique and didn't seem to take any interest in the outside world. They seemed to believe that BBC BASIC was the greatest thing since sliced bread, simply because they had never used anything else. This attitude seems to have been inherited by Archimedes owners, to a certain extent. > >The BASIC interpreter for the Archimedes takes up 30 bytes? I'm impressed. > > The interpreter is in ROM, therefore it does not take any RAM from the user, > you only have to take into account the tokenized form of the program, and > its workspace. I *KNOW* that. I know exactly what an interpreter is, what a compiler is, and what the merits are of both of them. The point is that to say that an interpreted BASIC program is better than a compiled C program because the BASIC source code is shorter than the compiled C is to be deliberately misleading. You can execute the compiled C in isolation, whereas you can't execute the BASIC. Now, if you are mentioning the size of an interpreted BASIC program and ignoring the kilobytes of support code in the BASIC ROM, then you should compare it with a system where the C support libraries are in ROM. You will then find that both programs are about the same size. As it happens, I think that the original poster was perfectly aware of this, and put a :-) to indicate that he wasn't being serious. I was being sarcastic in return. mathew.
ecwu61@castle.ed.ac.uk (R Renwick) (02/18/91)
In article <mT5eX12w163w@mantis.co.uk> mathew@mantis.co.uk (mathew) writes: >asmith@acorn.co.uk (Andy Smith) writes: >> In article <VBD0w17w163w@mantis.co.uk> mathew@mantis.co.uk (mathew) writes: >> >He said commercial SYSTEMS software. Little commercial systems software is >> >written in FORTRAN, and almost none in COBOL. FORTRAN is restricted almost >> >exclusively to scientific software, and COBOL is used almost exclusively >> >for business data processing. >> >> You mean these aren't commercial systems?? > >(*sigh*) > >Please learn the difference between commercial software systems and >commercial systems software. > Oh please, please, please do enlighten us mortals Mathew. [:-) Rik =============================================================================== ############ Richard Renwick ecwu61@uk.ac.ed.castle # # Computer Science 4 OR rlr@uk.ac.ed.lfcs @ ~~~ ~~~ @ University of Edinburgh |\@ ** ** @/| Edinburgh | @ ** ** @ | |/@ || @\| @ \ || / @ @ \______/ @ "Doesn't the grass look funny from underneath?" @ @ - Penfold @@@@@@@@@@ ===============================================================================
osmith@acorn.co.uk (Owen Smith) (02/20/91)
In article <1991Feb15.131220.7801@vax1.tcd.ie> hughesmp@vax1.tcd.ie writes: >Just out of interest, is there an equivalent of the BASIC 'DATA', 'READ', >and 'RESTORE' constructs in C, PASCAL, or MODULA2? You don't do it in the same way. In C, you would use static initialised structures (ie. a structure which already has data values put into it at compile time). This is much more efficient to access than DATA statements (a single LDR instruction for an integer value) and all the values can be randomly accessed at any time whereas READ is inherently sequential in nature. You can also over-write the initial values at runtime without any difficulty. Owen. (PS. Please can people stop cross-posting lots of stuff to eunet.micro.acorn) The views expressed are my own and are not necessarily those of Acorn.