The current SWdriver and SWCTL code was written in macro. There were two reasons: 1. Some parts already existed and could just be copied and edited. Since the code had been in use for some years, that meant less debugging. 2. I presumed it was necessary to run this code on VAX at least for client support. That means use Macro or Bliss, and I've never written anything in Bliss. That is now called into question, so there's an issue of whether to do the new code in C. There are some advantages to doing this: I'd get the experience of doing it from scratch and it may be easier to maintain just because folks who can read Macro-32 are said to be hard to find. Also the code would automatically be completely new and no history would need to be deleted. Rewriting in C means that c. 5000 lines of Macro-32 must be recreated from scratch in C. This would I presume mean maybe 1000 lines of C (presuming a rough 5:1 compression. The most serious disadvantage is the time to do this, even having a working example to build from. Coding at 50 lines a day for this stuff sounds optimistic and means roughly another month. On the other hand, the changes to the existing macro32 driver consist mainly in deleting sections of code that aren't needed (since it appears OK to go with having all IRPs appear at driver startio, and thus a second I/O queue is not needed, and all the cross checking for IRPs that appear at either pending_io or startio or both can be deep-sixed), and generalizing 2 paths to n paths (much of which is already built into data structures even in the test code). That's maybe a week by my estimate. There are a few technical hurdles. 1. Some of the entries that have to be revectored are called by JSB or even JMP (yes, on Alpha!) from inside the I/O exec. This is part of the external device driver interface and could be in use by code not visible on this floor. That at least will need to be handled in Macro; C lacks the ability to do it. 2. The actual interception scheme I have been relying on replaces the DDTAB with my own DDTAB, which is physically located in the intercept UCB. This is done so that negative offsets from the DDTAB can be used to get to the intercept UCB with a little pointer arithmetic. I must presume that C won't make this too hard, since I need to use sums of offsets in some places...the sort of thing expressed in Macro as ucb$l_myddt+ddt$ps_something for a simple example. This can be worked around with lots of temporary variables, and it should be possible to use casting to get around some of the grief, but this lookup operation is quite frequent and I am concerned with adding any more instructions to it than necessary. The existing code keeps frequently accessed items in registers heavily. I hope the C optimizer will be able to do this also even though they have to be treated at source level as though data all passes through memory. 3. Initializing some tables of addresses I use looks likely to become onerous. These are automatic in Macro; can they be so in C? (I use the indefinite - repeat MACRO builtin to populate a few tables.) Other aspects of the code look perfectly do-able in C.