Interesting bug

[Dan Pop]

I have never programmed in Fortran, but I think it was about the same
situation with the Fortran version Dan Pop grew up with.

Nope, FORTRAN IV was much better than BASIC and the "new" logical IF
statements were a great improvement over FORTRAN II's arithmetic IF
statements (which were gotos with 3 destinations).

Each program unit (main unit, functions and subroutines) had its own
local variables and it could be made to "see" only the global variables
it needed to see.

Its main drawbacks, that survived until F90, were the fixed-form line
format with purely numeric labels (characters beyond column 72 were
silently ignored, to provide additional fun during debugging) and blanks
being *completely* ignored in the statement field (starting in column 7),
except inside "string" literals. Hence the (in)famous typo:

DO 5 I = 1. 5

(the period was supposed to be a comma) that led to the statement being
parsed as:

DO5I = 1.5

i.e. a loop was replaced by an assignment to a bogus variable and the body
of the loop was executed once instead of 5 times. This happened in a NASA
program, but the consequences were minimal (a certain entity was evaluated
with less precision than intended).

Dan

 

[Chris Sonnack]

for(i=0;i<num;i++)
if(check(array))
break;
if(check(array))
continue;

As soon as I saw that code alarm bells went off my head.

Ditto. Bad code. Not interesting. :-|

 

[Richard Delorme]

Dan Pop a écrit :

The main purpose of many BASIC implementations was to make the best use
of the *limited* resources of 8-bit micros. One of the most popular
micros of the early eighties had 8k of ROM and 1k of RAM in its standard
configuration. Creative minds managed amazing feats on this
configuration.

The commodore-64 had 20K of ROM and 64K of RAM, so the memory resource
was not that much limited.

By the time BASIC moved to relatively resource-rich PC's, it also acquired
structured programming features (and even dropped the line numbers that
were supposed to replace the need for a "sophisticated" text editor).

According to Thomas E. Kurtz (co-inventor of BASIC), line number
suppression and structured programming appeared in their Dartmouth BASIC
around 1975, in order to avoid "spaghetti code":
http://www.truebasic.com/downloads/D2001.pdf
Of course, in 1975, no resource-rich PC was available.

Then again, no matter how many minds Dijkstra's paper might have changed,
there is plenty of proof that well structured code can be written with
gotos and badly structured code without. The tool might help, but it
cannot replace the skill of the craftsman.

Certainly, but it is quite clear to me that Dijkstra's paper changed
Kurtz & Kemeny minds so that they made their Dartmouth BASIC a fully
structured language, and that was several years before the release of
C-64 BASIC v2.

 

[Lew Pitcher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dan Pop a écrit :



The commodore-64 had 20K of ROM and 64K of RAM, so the memory resource
was not that much limited.



According to Thomas E. Kurtz (co-inventor of BASIC), line number
suppression and structured programming appeared in their Dartmouth BASIC
around 1975, in order to avoid "spaghetti code":
http://www.truebasic.com/downloads/D2001.pdf
Of course, in 1975, no resource-rich PC was available.



Certainly, but it is quite clear to me that Dijkstra's paper changed
Kurtz & Kemeny minds so that they made their Dartmouth BASIC a fully
structured language, and that was several years before the release of
C-64 BASIC v2.

Although Dijkstra and K&K were influencial in the field of programming at the
academic level, I believe that Dr. Dobbs was more influential on the formation
of C-64 Basic than they were.

Remember, until the Peoples Computer Company sponsored their "Tiny Basic"
contest (spawning "Doctor Dobb's Journal of Computer Calesthenics and
Orthodontia") there was /no/ BASIC for microcomputer. Since the source code for
about three or four "Tiny Basic"s were published by Dr. Dobbs, with the licence
to install them, and enhance them, from their authors, many (I'd dare say
'most') fuller-function microcomputer BASICs were derived from those humble and
restricted beginnings.


- --
Lew Pitcher
IT Consultant, Enterprise Application Architecture,
Enterprise Technology Solutions, TD Bank Financial Group

(Opinions expressed are my own, not my employers')
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)

iD8DBQFAiCSUagVFX4UWr64RAivrAJwMnxssqPjE/CERdnn7oQvZMNSXHgCgowaW
ORZdpx1jUt/ytUQxQIad5gA=
=Tyhx
-----END PGP SIGNATURE-----

 

[Joona I Palaste]

Dan Pop a écrit :

The commodore-64 had 20K of ROM and 64K of RAM, so the memory resource
was not that much limited.

So what caused the language to be so rudimentary?
For another thing, when the Commodore 64 was released, it had by far
the best graphics and sound capabilities on the market - if only people
could get to actually *use* them. The included BASIC did nothing
whatsoever to support anything beyond simple text output. You couldn't
even change the background colour, only the text colour.
To actually make use of the graphics and sound, you had to have
knowledge of how the VIC and SID chips operated and how they were
interfaced to various hard-coded registers in the 64-kilobyte memory
space. In practice this meant a lot of code consisting solely of
seemingly obscure POKE commands and PEEK functions. This code was
basically a BASICised form of machine code.
What caused this? Why didn't the BASIC have in-built graphics and sound
support? Many other competing machines did have it. Was Commodore in a
rush to get the machine released so they did not have the time?

 

[Chris Sonnack]

...Commodore 64...best graphics and sound capabilities on the market

Used intelligent "peripherals".

The included BASIC did nothing whatsoever to support anything beyond
simple text output. You couldn't even change the background colour,
only the text colour.

Are you sure about that? That doesn't match my memory.

Why didn't the BASIC have in-built graphics and sound support?

Wasn't there a SOUND() function and wasn't there Sprite support
at the BASIC level?

Or am I thinking of the C128 (I used both)?

 

[Keith Thompson]

Chris Torek wrote:
[...]

Errors are often a great deal easier to spot after all the irrelevant
distractions have been removed.

It is also easy to read what *should* have been written, rather
than what was actually written. This is particular true if the
debugging is being done by the original programmer.

Your brain knows what the code is supposed to be doing, and so you
"see" code that should be behaving. It's not uncommon for someone
to be debugging their own code for hours, only to call someone else
over who spots the error in under 30 seconds. (I've been on both
sides of that scenario.)

And sometimes explaining the code to someone else can help you find
the bug, even if the person you're explaining it to doesn't understand
a word you're saying.

I've read about a college computer lab that kept a toy stuffed bear
(or something similar). Students trying to figure out why their
programs were failing were expected to explain their code to the bear
before asking one of the lab assistants. Most of the time, talking to
the bear was enough to track down the problem.

 

[Keith Thompson]

Nope, FORTRAN IV was much better than BASIC and the "new" logical IF
statements were a great improvement over FORTRAN II's arithmetic IF
statements (which were gotos with 3 destinations).

Each program unit (main unit, functions and subroutines) had its own
local variables and it could be made to "see" only the global variables
it needed to see.

Its main drawbacks, that survived until F90, were the fixed-form line
format with purely numeric labels (characters beyond column 72 were
silently ignored, to provide additional fun during debugging) and blanks
being *completely* ignored in the statement field (starting in column 7),
except inside "string" literals. Hence the (in)famous typo:

DO 5 I = 1. 5

(the period was supposed to be a comma) that led to the statement being
parsed as:

DO5I = 1.5

i.e. a loop was replaced by an assignment to a bogus variable and the body
of the loop was executed once instead of 5 times. This happened in a NASA
program, but the consequences were minimal (a certain entity was evaluated
with less precision than intended).

This is a classic bug story, about which a great deal of
misinformation has been propagated over the years. There's a good
explanation of this bug (and the unrelated programming glitch that led
to the loss of the Mariner 1 Venus probe) in an article posted to
comp.lang.fortran back in 1994.

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&[email protected]

http://tinyurl.com/32fmf

The article was posted by some guy named "Dan Pop".

 

[Old Wolf]

Yes, but what were you going to do about it? C-64 Basic v2 had pretty
much the bare minimum of control structures. IF... THEN was only for
single lines, not blocks of lines, and there was no ELSE. The only loop
available was FOR... NEXT. Every other kind of loop had to be simulated
with IF... THEN GOTO. And like I said, GOTOs had to have hard-coded line
numbers as destinations. There was GOSUB... RETURN which I think could
be used to have "poor man's subroutines", because they behaved
otherwise like subroutines but had no concept of local variable scope.

Don't forget the BASIC equivalent of "switch":

240 GOTO 250*(i=0) + 350*(i=1) + 380*(i=2) + .... + 3530*(i=51)

(this came from an adventure game where there were 50 or so possible
user actions, each having its own handling "function").
Luckily my micro's version of BASIC included the feature of expressions
evaluating to either 1 or 0 (pretty advanced for those days); the other
micros had to do something more complicated.
I'm sure these program listings had to be generated by someone working
in a real environment with some tool that outputs micro-suitable
BASIC code, in real life it would take forever to re-number a program
and the programs were usually perfectly-numbered.

 

[Joona I Palaste]

Are you sure about that? That doesn't match my memory.

You could change the text colour by using PRINT to print various
control characters, which you could easily type by hand. To change the
background colour, you needed to POKE into the VIC's control registers.

Wasn't there a SOUND() function and wasn't there Sprite support
at the BASIC level?
No.

Or am I thinking of the C128 (I used both)?

You are.

 

[Joona I Palaste]

Don't forget the BASIC equivalent of "switch":

240 GOTO 250*(i=0) + 350*(i=1) + 380*(i=2) + .... + 3530*(i=51)

(this came from an adventure game where there were 50 or so possible
user actions, each having its own handling "function").
Luckily my micro's version of BASIC included the feature of expressions
evaluating to either 1 or 0 (pretty advanced for those days); the other
micros had to do something more complicated.
I'm sure these program listings had to be generated by someone working
in a real environment with some tool that outputs micro-suitable
BASIC code, in real life it would take forever to re-number a program
and the programs were usually perfectly-numbered.

On a Commodore 64, that GOTO statement will cause an "undef'd
statement" error if the variable i has any value from 0 to 51. This is
because unlike your micro's BASIC, the Commodore 64 BASIC evaluates
true expressions to -1, and thus if i has some value from 0 to 51,
the above GOTO will attempt to jump to a negative line number. It
should read:

240 GOTO -250*(i=0) - 350*(i=1) - 380*(i=2) - ... - 3550*(i=51)

 

[Dik T. Winter]

> The main purpose of many BASIC implementations was to make the best use
> of the *limited* resources of 8-bit micros.

That may have been the purpose of many later BASIC implementations, it
was not the purpose of the original BASIC. At that time the problem was
not limited resources on 8-bit micros, but limited resource on mainframes.

 

[Holger Hasselbach]

Used intelligent "peripherals".


Are you sure about that? That doesn't match my memory.


Wasn't there a SOUND() function and wasn't there Sprite support
at the BASIC level?

There simply was no space for it in the ROM. The C64 used bank
switching for the memory mapping:

64K RAM
$0000-$7fff 32K
$8000-$9fff 8K - Expansion slot
$a000-$bfff 8K - System ROM (Basic interpreter) - Expansion slot
$c000-$cfff 4K
$d000-$dfff 4K - IO (2xCIA, SID, VIC, 1Kx4 static color RAM)
$e000-$ffff 8K - System ROM (I/O)

The switching was controlled by 3 of the 6 I/O-lines of the 6510 CPU.
The other 3 bits were used for the Datasette tape recorder. 2 of the
CIA's I/O-lines controlled which of the 4 16K-portions of the RAM was
used for text, graphics and sprite data; the VIC-registers controlled
the exact location inside this 16K portion. The space for basic
programs was from $0800-$9fff in the standard configuration (still an
awful lot in comparision to other home computers).

Inside the 16K ROM there was anything: Datasette control, serial I/O
for peripherals, the complete basic interpreter, etc. It was used up
to the last bit. Basic extensions were usually made in three ways: In
hardware by using the expansion slot and losing 8K of RAM; by copying
the basic ROM into the RAM and modifying it; or by modifying one of
the indirect jump pointers heavily used for I/O and interpretation,
repointing it to the own routines.

---snip---------

What caused this? Why didn't the BASIC have in-built graphics and sound
support? Many other competing machines did have it. Was Commodore in a
rush to get the machine released so they did not have the time?

---snap---------

For a rush the complete thing was too bug-free. The strength of it was
that nearly *any* possibility given by the hardware was used in the
design, completely offering it to the competent programmer - not to
mention the internal "possibilities"/bugs of the I/O chips like the
frame sprites which were discovered quite lately. Not including
graphics and sound support into the Basic was IMHO a good idea - it
would have resulted in too much trade-offs.


Holger

 

[Richard Bos]

Your brain knows what the code is supposed to be doing, and so you
"see" code that should be behaving. It's not uncommon for someone
to be debugging their own code for hours, only to call someone else
over who spots the error in under 30 seconds. (I've been on both
sides of that scenario.)

This is not just true in computing, btw. I work for a publisher, and in
that business it is a well-known trope that it is all but impossible to
correct your own newspaper articles.

Richard

 

[Dan Pop]

Dan Pop a écrit :

The commodore-64 had 20K of ROM and 64K of RAM, so the memory resource
was not that much limited.

Maybe, maybe not. The 20K of ROM were probably holding plenty of code
that had nothing to do with the BASIC interpreter itself. There is also
the execution speed issue: GOTO lineno is much faster to implement in an
*interpreter* than scanning for the matching ELSE or reverse scanning to
find the beginning of the loop. Sure, such things can be accelerated,
by giving up the pure interpreter model, but this requires even more
resources.

The PC implementations supporting structured programming features
were typically incremental compilers...

Then, there is the marketing issue. The vast majority of C64's were not
supposed to be programmed in BASIC (or any other language), they were
supposed to be used as game machines. Games implemented in assembly.
Due to that, certain, game-oriented hadware features of the machine were
not even properly supported by the BASIC interpreter. So, the vendor
correctly (from HIS point of view) decided not to invest too much
resources into a sophisticated BASIC implementation where a simple minded
one could serve equally well.

And another argument, which I'm sure was ignored by Commodore, was that
the kids learning programming on such machines (the few seeing in the C64
more than a game machine) were better served by a very simple minded BASIC
along the lines of the original Kemenyi and Kurtz design, than by
something more sophisticated and, therefore, more difficult to grasp by
elementary school kids. I'm sure the really talented kids, who found
the limitations of the builtin BASIC annoying, could find better
alternatives.

According to Thomas E. Kurtz (co-inventor of BASIC), line number
suppression and structured programming appeared in their Dartmouth BASIC
around 1975, in order to avoid "spaghetti code":
http://www.truebasic.com/downloads/D2001.pdf
Of course, in 1975, no resource-rich PC was available.

So, they probably used resource-rich mainframes, so I fail to see your
point.

Certainly, but it is quite clear to me that Dijkstra's paper changed
Kurtz & Kemeny minds so that they made their Dartmouth BASIC a fully
structured language, and that was several years before the release of
C-64 BASIC v2.

So what? Are you suggesting that the resources of the C64 were comparable
to those of a mainframe from the mid-seventies?

Dan

 

[Joona I Palaste]

Maybe, maybe not. The 20K of ROM were probably holding plenty of code
that had nothing to do with the BASIC interpreter itself. There is also
the execution speed issue: GOTO lineno is much faster to implement in an
*interpreter* than scanning for the matching ELSE or reverse scanning to
find the beginning of the loop. Sure, such things can be accelerated,
by giving up the pure interpreter model, but this requires even more
resources.

A fully interpreted BASIC that scanned the actual source code as the
program progressed caused lots of interesting things. For example,
short line numbers actually performed better than long ones. Also
variables were faster than literal numbers. This was obvious, really,
as scanning a literal number required a decimal-to-binary conversion
but scanning a variable only required a table lookup. Thus several
magazines actually recommended replacing uses of 0 and 1 (which were
the most common numbers) with uses of variables that were assigned
these values and never reassigned.

The Commodore 64 actually used line numbers in a weird fashion. If we
ignore GOTO and GOSUB, line numbers were pretty much irrelevant.
Execution normally proceeded in the order the lines were in memory. If
you edited the memory directly, you could for example put the lines in
reverse order, or even give every line the same number, and the program
still ran like it originally did. (If it didn't use GOTO and GOSUB, of
course.)

The PC implementations supporting structured programming features
were typically incremental compilers...

Then, there is the marketing issue. The vast majority of C64's were not
supposed to be programmed in BASIC (or any other language), they were
supposed to be used as game machines. Games implemented in assembly.
Due to that, certain, game-oriented hadware features of the machine were
not even properly supported by the BASIC interpreter. So, the vendor
correctly (from HIS point of view) decided not to invest too much
resources into a sophisticated BASIC implementation where a simple minded
one could serve equally well.

And another argument, which I'm sure was ignored by Commodore, was that
the kids learning programming on such machines (the few seeing in the C64
more than a game machine) were better served by a very simple minded BASIC
along the lines of the original Kemenyi and Kurtz design, than by
something more sophisticated and, therefore, more difficult to grasp by
elementary school kids. I'm sure the really talented kids, who found
the limitations of the builtin BASIC annoying, could find better
alternatives.

Well, now we don't have that problem. Kids these days won't know a
programming language from a hole in the ground. What they want their
computer to do is access the latest "hip" chat sites and play the
latest action-packed shoot-'em-ups. Nothing that would actually require
creative thinking - heck, thinking at all.

--
/-- Joona Palaste ([email protected]) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"I said 'play as you've never played before', not 'play as IF you've never
played before'!"
- Andy Capp

 

[Dan Pop]

What caused this? Why didn't the BASIC have in-built graphics and sound
support? Many other competing machines did have it. Was Commodore in a
rush to get the machine released so they did not have the time?

Most likely, Commodore didn't see BASIC programming as relevant to the
marketing of a machine, which was, obviously, hardware optimised to
be used as a game console. However, since it was sold as a home computer
(another marketing trick: parents objecting to buying a game console
could be convinced to buy a home computer ;-) it had to have a BASIC
interpreter.

Compare to the ZX-Spectrum, that was poorly equipped as a game console,
but whose BASIC supported all the hardware features of the machine,
including the high resolution graphics and the sound generator (an I/O
port bit directly turning on and off the membrane of a loudspeaker).
It came with a very nice BASIC manual documenting everything (including
low level hardware and software implementation details) and a cassette
with demo BASIC programs (making minimal use of machine code to improve
the program's user interface). It's obvious that Clive Sinclair seriously
considered the educational usage of the machine, apart from its
recreational one (the machine also came with a very short user guide,
explaining how to connect it to the TV and tape cassette recorder and how
to load "programs" from tape).

Dan

 

[Dan Pop]

That may have been the purpose of many later BASIC implementations,

BASIC became really popular about 15 years after its original release.
Apparently, Bill Gates is responsible for that to a significant degree.

it
was not the purpose of the original BASIC. At that time the problem was
not limited resources on 8-bit micros, but limited resource on mainframes.

Or even machines lesser than mainframes, that could be used to serve
several terminals used for interactive BASIC programming. FOCAL was
an even more primitive-looking language, used for interactive programming
on the resource starved PDP-8 (4096 12-bit words).

Dan

 

[Dik T. Winter]

> Dan Pop <[email protected]> scribbled the following: ....
>
> A fully interpreted BASIC that scanned the actual source code as the
> program progressed caused lots of interesting things.

There is actually such a beast in the obfuscated c contest archives. It
is a C program of (I think) less than 2000 bytes.

 

[Dik T. Winter]

>
> Or even machines lesser than mainframes, that could be used to serve
> several terminals used for interactive BASIC programming. FOCAL was
> an even more primitive-looking language, used for interactive programming
> on the resource starved PDP-8 (4096 12-bit words).

Mainframes also were pretty resource starved. The first mainframe I used
had 32768 27-bit words, of which only one half could be used for code.
And that was the major mainframe serving two universities and the research
centre I worked at (and am still working at). Later this was changed to
a mainframe with 32768 60-bit words that could easily handle close to 100
interactive users, all doing Fortran, Algol 60, Algol 68 and Pascal
compilations and running editors and programs. But of course, your user
space was limited to 16384 words. And, eh, *no* virtual memory.