strick@gatech.UUCP (henry strickland) (10/19/84)
> Not only that, but source to cstart (the thing that does various jobs > of initialization and primitive argument parsing) is there as well. > One can hack up specialized versions of cstart and link them in to > one's code for various nefarious purposes. (For instance, a friend is - James Jones ==> The source to cstart is very interesting. A little reading there will yield a lot of understanding about how Microware C works. I once wrote a hard disk driver in Microware C (level 1) for a student project. The disk had a very intelligent hardware controller with an asynchronous handshaking interface, so speed was never a critical issue. I wanted to use C rather than assembler because of the rather massive mount of async protocol. I really hate writing assembler. The cstart module is strictly for executable programs, not device drivers. I wrote my own assembly language 'start' module to vector the six 'lbra' entry points to six instances of a macro that sets up the registers for C. For instance, the Y register needs to point to your static storage in Microware C, rather than the U register. And the direct page register also needs to be set to the static page. The macro saves the stack pointer in a static register, and then calls the appropriate C function (init(), read(), ...). Also in assembler I wrote an exit() that restores the sp from the static reg, arranges error condition if needed, and returns. The only problem I couldn't resolve with the compiler was that a driver has one more byte in the header than an executable program: there is a mode byte that I wanted to be $FF, but the loader insists on putting the name of the module at that location. My solution was to append an extra 'Z' to the front of my module name and then zap it to $FF, increment the pointer to the module name (bytes 4 & 5 of the header), and send it through "verify u". I had no problems with compiler bugs in about 10 pages of C source. ==> While chatting about Microware C: I've always had the feeling that it wouldn't be very hard to change the profiler to rather than count calls to funtions, and summarize at the end, to actually do something debug-wise on each function call, such as print out the name of the subroutine and some of the stack (likely the arguments to the function). This seems like a beautiful debugging hook we could be using . . . [James, you have the source to prof, right? Have any free time? :+] ==> It seems that we OS9 people are the only group using net.micro.6809, so why don't we just stay here? The OS9:68K people would not have to wade through much to find the OS9 material. ==> Try hitting ctrl-a right after booting. I have a friend that changed his (by no means easy!)! hint: it's in SCF. -- -- henry strickland -- the clouds project { akgua allegra hplabs inhp4 } -- school of ics / ga tech !gatech!strick -- atlanta ga 30332