| In my day job, I work in a company that is into generation of device drivers from a high level specification - so I can talk forever on this topic! But other comments here are already spot on - and I don't have much to add. But the question assumes(?) that the P language is meant for writing device drivers - and IMHO that assumption is not entirely true, for the language doesn't have any constructs for capturing the software's (the "physical device driver's" [1]) interaction with hardware. For instance, I don't see a way to capture :
1. Software programmable registers (MMIO or over PCIe, I2C etc)
2. The software's contribution in DMA by setting up descriptors and buffers correctly and efficiently
3. Interrupts that the hardware can raise and how software should service them
4. Sequences to negotiate device capabilities and configuration, reset, perform transmit/receive, etc. Many other comments here touch upon these and other aspects as being characteristic of "device drivers", they are missing altogether in the P language (I read the manual, didn't check the source, but I'm quite sure). There is a "higher" driver - a logical device driver (LDD, [1]). An implementation of LDD is not specific to a device hardware (from some vendor); it remains same across all devices in a certain category. So an LDD is usually supplied/maintained by the OS vendor. For those who are aware of the WinCE architecture, the LDD is called an MDD ([2]). The P language does seem to enable is specification of LDD - as long as it lends itself to the "message passing machines" paradigm (and in that respect, LDD is no more special to the P-language than any other software that can be modeled using "message passing machines"). References [1] https://en.wikipedia.org/wiki/Device_driver - distinction between PDD and LDD [2] https://msdn.microsoft.com/en-us/library/aa447512.aspx |