milikich@iccgcc.decnet.ab.com ((Mike Milikich), Allen-Bradley Company) (09/12/90)
This is probably a really dumb question, but please bear with me - I'm just getting started. Inside Mac Vol. II-6 desribes all sorts of neat stuff about device drivers, but also makes some sort of statement about how they are normally written in assembler. Is this just a dated statement, or is it still accurate? It seems unlikely that it wouldn't be possible to write a serial driver, say, in Think C. Anyone/everyone want to set me straight? Mike Milikich -------------------------------------------------------------------------------- | milikich%iccgcc.decnet@consrt.rok.com |"...and the men who hold high places | | allen-bradley company | must be the ones to start..." | | 747 alpha drive |--------------------------------------| | highland heights, ohio 44143 | I don't speak for A-B, | | (216) 646-3494 FAX : (216) 646-4343 | and I know they don't speak for me. | --------------------------------------------------------------------------------
jason@ux1.cso.uiuc.edu (Jason) (09/13/90)
milikich@iccgcc.decnet.ab.com ((Mike Milikich), Allen-Bradley Company) writes: >Inside Mac Vol. II-6 desribes all sorts of neat stuff about device drivers, but >also makes some sort of statement about how they are normally written in >assembler. Is this just a dated statement, or is it still accurate? It seems >unlikely that it wouldn't be possible to write a serial driver, say, in >Think C. Anyone/everyone want to set me straight? Think C _does_ allow you to create device drivers/desk accessories, and rather painlessly. When you identify your project as being a driver/DA (from the "Project, Set Project Type..." dialog), Think adds "glue" code to the beginning of your driver to make it look and behave as the Macintosh expects it to. The main() function itself is passed the i/o parameter block pointer, the device control entry pointer, _and_ a message parameter (similar to those in defProcs, like CDEFs) which tells the driver which function to perform (i.e., Open, Prime, Control, Status, or Close). This message can be used as a selector in a switch-case block to cause execution to branch to the appropriate routine. -- | | |====================| | | | Jason Watts | \ |\ |\ \ | (jazzin@uiuc.edu) |
minich@d.cs.okstate.edu (Robert Minich) (09/13/90)
|Inside Mac Vol. II-6 desribes all sorts of neat stuff about device drivers, but |also makes some sort of statement about how they are normally written in |assembler. Is this just a dated statement, or is it still accurate? It seems |unlikely that it wouldn't be possible to write a serial driver, say, in |Think C. Anyone/everyone want to set me straight? I think the original point was probably closer to "...because device drivers must access some low level structures, at least SOME assembly is required..." IM I-III were written back when you had to use a Lisa to program for the Mac and the high level language was Pascal, which doesn't do low level things too well. With THINK C, you get the inline assembler which should satisfy any need you might have wrt writing a driver. Good Luck! -- |_ /| | Robert Minich | |\'o.O' | Oklahoma State University| There are no heroes -- |=(___)= | minich@a.cs.okstate.edu | We all wear gray hats. | U | - Ackphtth |
stevec@Apple.COM (Steve Christensen) (09/13/90)
In article <872.26ee1d0a@iccgcc.decnet.ab.com> milikich@iccgcc.decnet.ab.com ((Mike Milikich), Allen-Bradley Company) writes: >This is probably a really dumb question, but please bear with me - I'm just >getting started. > >Inside Mac Vol. II-6 desribes all sorts of neat stuff about device drivers, but >also makes some sort of statement about how they are normally written in >assembler. Is this just a dated statement, or is it still accurate? It seems >unlikely that it wouldn't be possible to write a serial driver, say, in >Think C. Anyone/everyone want to set me straight? No, you can write a driver in whatever language you want, since you ultimately end up with assembly language anyway. As long as the header has the correct info, it doesn't really matter how the rest of the driver is done. I wouldn't want to make a comment on whether or not the bit about writing drivers in assembly is dated, but I think the reason for doing it that way is that you have much more control over the generated code if it's written is assembly (vs a high-level language like C) for those cases where timing issues are critical... steve -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ whoami? Steve Christensen snail: Apple Computer, 20525 Mariani Ave, Cupertino, CA 95014 Internet: stevec@goofy.apple.com AppleLink: stevec CompuServe: 76174,1712
mneerach@inf.ethz.ch (Matthias Ulrich Neeracher) (09/13/90)
In article <10178@goofy.Apple.COM> stevec@Apple.COM (Steve Christensen) writes: >In article <872.26ee1d0a@iccgcc.decnet.ab.com> milikich@iccgcc.decnet.ab.com ((Mike Milikich), Allen-Bradley Company) writes: [...] >>Inside Mac Vol. II-6 desribes all sorts of neat stuff about device drivers, but >>also makes some sort of statement about how they are normally written in >>assembler. Is this just a dated statement, or is it still accurate? It seems >>unlikely that it wouldn't be possible to write a serial driver, say, in >>Think C. Anyone/everyone want to set me straight? >No, you can write a driver in whatever language you want, since you ultimately >end up with assembly language anyway. As long as the header has the correct >info, it doesn't really matter how the rest of the driver is done. I wouldn't >want to make a comment on whether or not the bit about writing drivers in >assembly is dated, but I think the reason for doing it that way is that you >have much more control over the generated code if it's written is assembly >(vs a high-level language like C) for those cases where timing issues are >critical... I think that the reason to make this statement was also that at that time, it was *very* difficult to get the header right. Today, MPW manages this with its powerful resource compiler and linker and the Think languages have the driver case as a built-in possibility, but things were different when this statement was written. Even today, most development systems have difficulties with automatically generating unusual headers. As an example, the HP DeskJet driver sources that recently were posted needed a considerable effort to create the correct headers for the PDEF resources in LightSpeed C. When I ported them to MPW, I just wrote the headers in assembler. So I don't think control over the generated code is such a problem, except for resource headers and register saving conventions. Matthias ----- Matthias Neeracher mneerach@inf.ethz.ch "I wouldn't recommend sex, drugs or insanity for everyone, but they've always worked for me" -- Hunter S. Thompson