Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!uunet!mcsun!hp4nl!star.cs.vu.nl!gpvos
From: gpvos@cs.vu.nl (Gerben 'P' Vos)
Newsgroups: comp.sys.acorn
Subject: Re: BBC keyboards - forwarding a posting
Message-ID: <9324@star.cs.vu.nl>
Date: 15 Mar 91 11:10:47 GMT
References: <vanaards.668436483@p4.cs.man.ac.uk> <2900@krafla.rhi.hi.is>
Sender: news@cs.vu.nl
Lines: 21

kvj@rhi.hi.is (Kristjan Valur Jonsson) writes:

>The reason is that when all the G.0: 's are expanded into GOTO0: 's, the input
>buffer overflows into other buffers down in the OS's workspace (below &E00),
>and mainly into the sound buffer.

No. The G. gets compressed to a single token, just like a GOTO would.
The 0 expands, because line numbers after a GOTO (or RESTORE, or THEN <line>)
are encoded, so BASIC doesn't have to parse the decimal number, which would
be slow compared to just decoding the binary bytes. A line number is expanded
to a token (&8D, from the top of my head) and three bytes (it could have been
two, but that has some complications when one of them would be a CR or even an
ELSE token).

So "G.0:" expands from 4 bytes to 5, which causes the mentioned effects.

-                                       Gerben
--
--- Gerben Vos - Aconet: BIGBEN!Gerben Vos - Internet: gpvos@cs.vu.nl <><
---- The question if a computer can think is as interesting as the question if
----- a submarine can swim. -- E. Dijkstra