[Info-vax] VMS Software Q1 '23 Update

[Johnny Billquist]

On 2023-01-31 15:07, Simon Clubley wrote:
> On 2023-01-30, Johnny Billquist <bqt at softjar.se> wrote:
>> On 2023-01-29 15:51, Simon Clubley wrote:
>>> On 2023-01-29, Arne Vajhøj <arne at vajhoej.dk> wrote:
>>>> On 1/29/2023 1:21 AM, Dave Froble wrote:
>>>>> On 1/28/2023 10:44 PM, Arne Vajhøj wrote:
>>>>>> Could PDP-11 do 32 bit integers?
>>>>>
>>>>> What part of "signed word integers" didn't you understand?  As in 16
>>>>> bits. -32768 to 32767.
>>>>
>>>> I sort of had guessed that word was the same as on VAX,
>>>> but I don't understand how it can't have a 32 bit integer.
>>>>
>>>> How does one work with file sizes and file position
>>>> in bytes on PDP-11?
>>>>
>>>
>>> The same way as it's done with a block-based filesystem (ODS-2) on VMS.
>>
>> If you look at the QIO functions to F11ACP in RSX, the block number take
>> two parameters, in order to be 32 bits. Fields in RMS structures are
>> simply just 32 bits where needed, if you deal at it at that level.
>>
>>> In general, the 16-bit nature of the PDP-11 is reflected in the API.
>>
>> Not sure which API you are referring to here. The QIO interface
>> obviously have just 16-bit wide arguments, so something like the block
>> number needs to parameter values for the full 32 bits.
>> Most other APIs (such as FCS or RMS) just define 32-bit values where needed.
>>
> 
> The system services/syscalls/whatever they were called on PDP-11.

I guess the really correct term in RSX is directives.
As calls such as QIO to access some block is using a 32-bit number, you 
might argue that it deals with 32-bit integers then. Even if it have to 
provide the high and low 16 bits as two separate values. But they are 
just interpreted together as a 32-bit value all the time.

>>> Ever worked with real-mode MS-DOS at assembly language level ?
>>>
>>> It's the same kind of thing.
>>
>> No. Not at all comparable. The PDP-11 is rather different than the x86.
>> There was never far pointers, segment registers, or all the weird stuff
>> of MS-DOS.
>>
> 
> The reference was to having to string together 16-bit chunks of a number
> into a larger value instead of just being able to directly write into a
> 32-bit register in 32-bit chunks.

Well, that is true for just about any CPU, for anything larger than just 
fits into one register. Both PDP-11 and VAX string multiple registers 
together for some operations for larger values than fit in one register.
And same when in memory.

>>>> I know you don't do C, but I believe C was invented on
>>>> PDP-11.
>>>>
>>>
>>> What makes you think that "int" in C is _always_ at least 32 bits ? :-)
>>>
>>> There's a reason why both int and long int have always existed in C.
>>>
>>> And on architectures that do not support 32-bit ints, then long int is
>>> a library/RTL feature implemented by the language in the same way as
>>> 64-bit long long int is implemented by the language RTL on 32-bit
>>> architectures.
>>
>> Um. Not necessarily. The compiler can just know how to do 32-bit
>> operations on a 16-bit machine, and generate the code straight off, even
>> if it's a bit more complex than simple 16-bit operations.
>>
>> And that is what I see for PDP-11 C for example.
>>
> 
> It's still something that has to be implemented in the generated compiler
> code instead of it being able to directly write into a 32-bit register in
> 32-bit chunks.

Well, the compiler needs to implement the moving into one register as 
well. Nothing happens automatically. So - moving to one register, or 
two. What's the big deal? Same thing with arithmetic.
No library/RTL actually needed for the simple stuff.

>>> Also, most languages on RSTS/E intended for commercial data processing
>>> also supported a decimal datatype, which was implemented by the language's
>>> RTL. It seems early RSTS/E Basic wasn't one of them however, based on
>>> what David is saying.
>>
>> You could definitely argue that the numeric strings are a decimal data type.
>>
> 
> I would not disagree with that. Having never really used DEC Basic,
> I had forgotten about them until you brought them up.

At one point I did some financial code in BASIC, very long time ago, and 
then I did use those functions because they just seemed more precise.

With that said, I had also forgotten about "==" which is used to check 
for approximate equality of FP in BASIC+.

> Did they exist back in the V4 days when David started writing his code ?

That is a good question. I can't say for absolutely sure, but I did find 
a BASIC+ manual from V6, and couldn't find it in there, so I suspect 
not. Next I checked V10, and there it is in the manual. Couldn't find 
any manual in between on a quick search.

   Johnny