Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!ut-sally!im4u!rutgers!sri-spam!ames!ptsfa!ihnp4!ihwpt!knudsen From: knudsen@ihwpt.ATT.COM (mike knudsen) Newsgroups: comp.sys.m6809 Subject: Re: True Multitasking, and some history lessons Message-ID: <1738@ihwpt.ATT.COM> Date: Fri, 12-Jun-87 17:43:37 EDT Article-I.D.: ihwpt.1738 Posted: Fri Jun 12 17:43:37 1987 Date-Received: Sun, 21-Jun-87 01:30:02 EDT References: <8706040024.AA10895@cogsci.berkeley.edu> <2194@husc6.UUCP> <28419@rochester.ARPA> Organization: AT&T Bell Laboratories - Naperville, Illinois Lines: 66 Summary: shared libraries problems why not done in 6809? > > > Library of stdio ... good idea, anyone want to tackle it? > > > Rob Peck ...hplabs!dana!rap > > I'm just a "lowly" Coco-3 (6809) hacker, but I seem to recall > > that OS/K (68000 OS9) does indeed share the whole stinkin' > > StdIO library, so when you have a half dozen C programs loaded, > OS-9/68K supports "trap handlers." Two of them come with the system: > a stdio trap handler and a floating point trap handler. The program > does some fussing around to "install" the handler, then it uses > a trap to access the routines in the handler. You need a trap per > trap handler, so there is a limit on the number of separate libraries > a program can use without swapping trap numbers around. > > The technical manual describes the protocol for the floating point > handler. The stdio handler is undocumented, and it looks a bit > tricky to call. > > On the 6809 subroutine modules could be used to achieve almost > the same effect. > Peter Dibble Thanks for the facts, Peter. BTW, I'm cutting this back to just .m6809; I don't think the Big A's want to hear the OS9 details. Seems to me that however you do a shared stdio (C runtime) library, at least some of its code has to map into your process's space during the call. (Yes, 6809 subr modules would do just fine.) This is because of the random way you can throw variables from your program into a printf() or scanf() call. The stdio function has to map into your process space to find all those goodies. Of course this is no worse than a non-shared set of stdio routines. But I'm a little confused by OS/K's trap handlers. Are these in system space? If so, how do they get to the caller's variables? I guess there is no problem in OS/K Level 1, and since a 68K can address 16M, maybe nobody cares that it won't work as easily under Level 2 OS/K. (Microware even advertises a Level 3 OS/K, with swapping or paging to hard disk). Since Atari and Amiga have no MMU/DAT, OS/K Level 1 is all that matters to them for now. (restricted distribution ==> no flames this time!) As for why shared libes haven't been tried on 6809 -- I guess it hasn't been worth the hassle, with relatively few applications written in C. When you relize that all your assembly-coded programs all have their own binary-to-BCD output translation routines (ok, Hex in OS9) you may wish these things were shared. But now with C-coded programs (like Dynastar) available for the Coco 3, it may be worthwhile to rewrite stdio to use subroutine modules. The cstart() fcn linked into your final object code could ensure that the required modules got LOADed just once. Your code would contain just the argument-grabbing opening lines of printf() and its friends. Then the main bulk of printf() and such would be LINKed and UNLINKed on each call. Or (horrors!!) turn things upside down--put the runtime package of C in charge, such that it runs your main() in much the same way that BASIC09 interpreter runs I-code. BTW, BASIC09 does great with 6809 subr modules (Inkey, GFX, GFX2, etc). I may be over my head here, and Microware probably doesn't need any more suggestions this week, but ... oh, well. -- Mike J Knudsen ...ihnp4!ihwpt!knudsen Bell Labs(AT&T) Delphi: RAGTIMER CIS: "Just say NO to MS-DOS!"