[Info-vax] Compatibility and 64-bit

[Stephen Hoffman]

On 2015-03-15 07:08:43 +0000, David Froble said:

> Stephen Hoffman wrote:
>> On 2015-03-14 23:59:22 +0000, David Froble said:
> 
>>> As someone who write a bunch of stuff using Basic, but who also plays 
>>> around with data in string descriptors, I can see some nasty surprises 
>>> coming if backward compatibility is abandoned.
>> 
>> Which is part of why — if things are looking forward, and not backward 
>> — descriptor support needs to get a whole lot better and simpler, which 
>> might well end up with the APIs and the descriptors and the rest 
>> becoming objects.  Both Windows and OS X have provided OO APIs for most 
>> of the system frameworks and tools — think itemlists in terms of 
>> flexibility, but with no glue code needed.
> 
> About the string descriptors ....
> 
> I use them as labels in I/O buffers.  Modify the location (pointer) and 
> length.  Any changes to the existing string descriptors I use will be a 
> problem, as far as I can see.

You'd obviously need a BASIC compiler and run-time that generated 
64-bit code, and that's probably not very high on anybody's list right 
now.

Adding 64-bit would allow you to handle huge piles of data in memory, 
but probably not a whole lot else that was new and useful.   (I'd hold 
out for unsigned integer support, but...)

Moving to 64-bit addressing probably won't be all that visible within 
most BASIC code, except where you might be saving off addresses via LOC 
— which is documented to return a longword, not a quadword — into some 
existing longword-sized variable, as would be the case with various 
"home-made" descriptors or with the 32-bit or 64-bit itemlists.   The 
receiving variable will need to be bigger, and either LOC modified or 
some LOC64 call added.  There are also cases when some BASIC code calls 
out to external routines that are expecting descriptor arguments, and 
those are now potentially or likely passed a 64-bit descriptor for some 
data structure or some string in P2 space.  That might cause some 
run-time indigestion.

Should the size of the default IMPLICIT integer be increased, that 
might also blow out compatibility with existing non-volatile data 
structures.   (But there doesn't seem to be a huge reason to change the 
IMPLICIT.)

What happens here depends a great deal on the existing BASIC code.  
Most BASIC code probably won't notice 64-bit.



-- 
Pure Personal Opinion | HoffmanLabs LLC