[Info-vax] VMS Software Q1 '23 Update

[Simon Clubley]

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:
>>>>> On 1/28/2023 10:39 PM, Dave Froble wrote:
>>>>>> On 1/28/2023 8:28 PM, Scott Dorsey wrote:
>>>>>>> One of the absolute FIRST things that I was told about floating point
>>>>>>> variables in my first programming class was to NEVER use them to
>>>>>>> represent
>>>>>>> money.
>>>>>>
>>>>>> What if you didn't have a choice?
>>>>>>
>>>>>> RSTS/E V04b
>>>>>>
>>>>>> Signed word integers
>>>>>> Strings
>>>>>> Single and double D-float
>>>>>>
>>>>>> That's all there was ...
>>>>>
>>>>> There is always integers and implied decimal.
>>>>>
>>>>> Not fun though.
>>>>>
>>>>> And one need an integer with enough bits ...
>>>>>
>>>>> 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.

>> 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.

>>> 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.

>> 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.

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

Simon.

-- 
Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.