[comp.sys.acorn] More about BASIC vs. Pascal vs. C

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.