On 2024-01-12, Single Stage to Orbit <alex.buell@munted.eu> wrote:
> On Fri, 2024-01-12 at 01:46 +0000, Gary Sparkes wrote:
>> I'm highly waiting on this, while testing some devices and code in
>> Alpha and Itanium systems, for when that floodgate opens. A fair
>> amount of things i'm working on are hardware support for specialty
>> things, and lack of being able to (so far) load my own drivers
>> without some insane steps is... well, putting things on hold for
>> people who're excited to get rid of some older hardware.
>
> I've been told writing drivers for OpemVMS/x86 is an insane process!

Even more so than writing one for Alpha ?

If so, how did they manage to make the process even more insane ?

Simon.

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

On 1/12/2024 9:20 AM, Simon Clubley wrote:
> On 2024-01-12, Single Stage to Orbit <alex.buell@munted.eu> wrote:
>> On Fri, 2024-01-12 at 01:46 +0000, Gary Sparkes wrote:
>>> I'm highly waiting on this, while testing some devices and code in
>>> Alpha and Itanium systems, for when that floodgate opens. A fair
>>> amount of things i'm working on are hardware support for specialty
>>> things, and lack of being able to (so far) load my own drivers
>>> without some insane steps is... well, putting things on hold for
>>> people who're excited to get rid of some older hardware.
>>
>> I've been told writing drivers for OpemVMS/x86 is an insane process!
>
> Even more so than writing one for Alpha ?
>
> If so, how did they manage to make the process even more insane ?
>
> Simon.
>

While I'm not a device driver expert, x86 device drivers should function
much like their prior counterparts. There are a few areas that changed.

Interesting fields in the PTEs (page table entries) moved from the
bottom 32-bits to the upper 32-bits (x86 architecture defined these)
so Macro-32 written drivers had to inspect the various instructions
and change to EVAX_ 64-bit instructions. I believe that macros were
written to hide those details but some drivers might have been rewritten
into C in the process. [I'm a big fan of eliminating Macro-32 code.
I have a long-standing joke of paying $5 per module for any rewrite out
of Macro-32 into ANY other language.]

The other area was with a concept SVAPTE (System Virtual Address PTE)
where a piece of 64-bit memory was double-mapped to also be accessible
using 32-bit system addresses. Such a concept didn't fit with how the
x86 memory management was going to work so all the SVAPTE references
where modified/buried in a macro along with expansion of some of those
32-bit fields into 64-bit fields. [Don't quote me on the exact details
of these changes.]

However, there were no large conceptual changes to the device driver
architecture for x86.

On Fri, 2024-01-12 at 11:43 -0500, John Reagan wrote:
> While I'm not a device driver expert, x86 device drivers should
> function much like their prior counterparts.  There are a few areas
> that changed.
>
> Interesting fields in the PTEs (page table entries) moved from the
> bottom 32-bits to the upper 32-bits (x86 architecture defined these)
> so Macro-32 written drivers had to inspect the various instructions
> and change to EVAX_ 64-bit instructions.  I believe that macros were
> written to hide those details but some drivers might have been
> rewritten into C in the process.  [I'm a big fan of eliminating
> Macro-32 code. I have a long-standing joke of paying $5 per module
> for any rewrite out of Macro-32 into ANY other language.]
>
> The other area was with a concept SVAPTE (System Virtual Address PTE)
> where a piece of 64-bit memory was double-mapped to also be
> accessible using 32-bit system addresses.  Such a concept didn't fit
> with how the x86 memory management was going to work so all the
> SVAPTE references where modified/buried in a macro along with
> expansion of some of those 32-bit fields into 64-bit fields.  [Don't
> quote me on the exact details
> of these changes.]
>
> However, there were no large conceptual changes to the device driver
> architecture for x86.

Interesting to know. Are there any documentation and are there any
example drivers that would be useful. I think a good starting point
might be to add USB drivers for keyboard and mouse input. These
definitely will be useful for bare metal on x86 hardware.

Does x86 already has support for NVME and AHCI devices?
--
Tactical Nuclear Kittens

On 12/01/2024 16:43, John Reagan wrote:
I'm a big fan of eliminating Macro-32 code.
> I have a long-standing joke of paying $5 per module for any rewrite out
> of Macro-32 into ANY other language.

When I joined our programming team in the 90's, I made it clear that I
would not attempt to learn macro. I didn't.

I later did the port from Alpha to Itanium, and I found one piece of
macro code that didn't work, so I rewrote in DEC Basic. It was helpful
that the function well documented as to it's parameters, and output, so
it worked 100%

Do I get a fiver? ;)

--
Chris

On 1/12/2024 7:13 PM, Chris Townley wrote:
> On 12/01/2024 16:43, John Reagan wrote:
> I'm a big fan of eliminating Macro-32 code.
>> I have a long-standing joke of paying $5 per module for any rewrite out
>> of Macro-32 into ANY other language.
>
> When I joined our programming team in the 90's, I made it clear that I
> would not attempt to learn macro. I didn't.
>
> I later did the port from Alpha to Itanium, and I found one piece of
> macro code that didn't work, so I rewrote in DEC Basic. It was helpful
> that the function well documented as to it's parameters, and output, so
> it worked 100%

I believe there are a lot of totally unnecessary Macro-32 code out there.

If I were to make a guess about it:

60% written in Macro-32 in VAX days for performance reasons but without
actually improving performance

39% written in Macro-32 in VAX days for performance reasons and actually
did improve performance on VAX but performance is worse on
Alpha/Itanium/x86-64

0% written in Macro-32 in VAX days for performance reasons and actually
do improve performance on all platforms

1% written in Macro-32 to do something not easily expressed in HLL

Arne

On 1/12/2024 7:19 PM, Arne Vajhøj wrote:
> On 1/12/2024 7:13 PM, Chris Townley wrote:
>> On 12/01/2024 16:43, John Reagan wrote:
>> I'm a big fan of eliminating Macro-32 code.
>>> I have a long-standing joke of paying $5 per module for any rewrite out
>>> of Macro-32 into ANY other language.
>>
>> When I joined our programming team in the 90's, I made it clear that I
>> would not attempt to learn macro. I didn't.
>>
>> I later did the port from Alpha to Itanium, and I found one piece of
>> macro code that didn't work, so I rewrote in DEC Basic. It was helpful
>> that the function well documented as to it's parameters, and output,
>> so it worked 100%
>
> I believe there are a lot of totally unnecessary Macro-32 code out there.
>
> If I were to make a guess about it:
>
> 60% written in Macro-32 in VAX days for performance reasons but without
> actually improving performance
>
> 39% written in Macro-32 in VAX days for performance reasons and actually
> did improve performance on VAX but performance is worse on
> Alpha/Itanium/x86-64
>
> 0% written in Macro-32 in VAX days for performance reasons and actually
> do improve performance on all platforms
>
> 1% written in Macro-32 to do something not easily expressed in HLL

Note that I am guilty myself.

In the late 80's and early 90's I liked to write all code
deemed low-level in Macro-32.

All IO using SYS$QIOW.

And even stranger wrappers around PPL$ and MAIL$ functions.

WTF????

Arne

On 1/12/24 6:19 PM, Arne Vajhøj wrote:
> On 1/12/2024 7:13 PM, Chris Townley wrote:
>> On 12/01/2024 16:43, John Reagan wrote:
>> I'm a big fan of eliminating Macro-32 code.
>>> I have a long-standing joke of paying $5 per module for any rewrite out
>>> of Macro-32 into ANY other language.
>>
>> When I joined our programming team in the 90's, I made it clear that I
>> would not attempt to learn macro. I didn't.
>>
>> I later did the port from Alpha to Itanium, and I found one piece of
>> macro code that didn't work, so I rewrote in DEC Basic. It was helpful
>> that the function well documented as to it's parameters, and output,
>> so it worked 100%
>
> I believe there are a lot of totally unnecessary Macro-32 code out there.
>
> If I were to make a guess about it:
>
> 60% written in Macro-32 in VAX days for performance reasons but without
> actually improving performance
>
> 39% written in Macro-32 in VAX days for performance reasons and actually
> did improve performance on VAX but performance is worse on
> Alpha/Itanium/x86-64
>
> 0% written in Macro-32 in VAX days for performance reasons and actually
> do improve performance on all platforms
>
> 1% written in Macro-32 to do something not easily expressed in HLL

It was common a decade or three ago to write code in MACRO because it
was the only thing besides DCL that was guaranteed to be there.
Compilers for the other languages were expensive.

On 1/12/2024 7:19 PM, Arne Vajhøj wrote:
> On 1/12/2024 7:13 PM, Chris Townley wrote:
>> On 12/01/2024 16:43, John Reagan wrote:
>> I'm a big fan of eliminating Macro-32 code.
>>> I have a long-standing joke of paying $5 per module for any rewrite out
>>> of Macro-32 into ANY other language.
>>
>> When I joined our programming team in the 90's, I made it clear that I would
>> not attempt to learn macro. I didn't.
>>
>> I later did the port from Alpha to Itanium, and I found one piece of macro
>> code that didn't work, so I rewrote in DEC Basic. It was helpful that the
>> function well documented as to it's parameters, and output, so it worked 100%
>
> I believe there are a lot of totally unnecessary Macro-32 code out there.
>
> If I were to make a guess about it:
>
> 60% written in Macro-32 in VAX days for performance reasons but without actually
> improving performance
>
> 39% written in Macro-32 in VAX days for performance reasons and actually did
> improve performance on VAX but performance is worse on Alpha/Itanium/x86-64
>
> 0% written in Macro-32 in VAX days for performance reasons and actually do
> improve performance on all platforms
>
> 1% written in Macro-32 to do something not easily expressed in HLL
>
> Arne
>

The bottom line is, MAcro-32 is an assembly language for the VAX. It is NOT for
follow on processors. So, there should not be any reason to write new Macro-32
after VAX. The only reasonable use for the Macro-32 compiler is to run existing
code.

That said, there probably be some exception somewhere. Rare exception.

I will say that the compiler sure saved my ass when moving to Alpha and itanic.
And if it happens, to x86 also.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486