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!
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.
I have a long-standing joke of paying $5 per module for any rewrite out
of Macro-32 into ANY other language.
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%
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
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
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
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 432 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 31:06:43 |
| Calls: | 9,081 |
| Calls today: | 4 |
| Files: | 13,409 |
| Messages: | 6,022,251 |