* [9fans] Data segment vs BSS @ 2006-01-31 4:36 Noah Evans 2006-01-31 5:09 ` jmk 0 siblings, 1 reply; 22+ messages in thread From: Noah Evans @ 2006-01-31 4:36 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Bell Labs Hey, quick 2l question. Is there any way to keep constant values in ROM? If possible I'd like to keep the data section entirely in ROM and only keep the BSS section in RAM. However, both sections seem to be inextricably linked. What's the proper way to deal with this? Noah ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [9fans] Data segment vs BSS 2006-01-31 4:36 [9fans] Data segment vs BSS Noah Evans @ 2006-01-31 5:09 ` jmk 2006-01-31 5:35 ` Noah Evans 0 siblings, 1 reply; 22+ messages in thread From: jmk @ 2006-01-31 5:09 UTC (permalink / raw) To: 9fans The normal Plan 9 binary format assumes the BSS starts immediately after the data, there is no place in the header to specify otherwise. So, you want to use a different header format, e.g. ELF or one of the machine-specific boot formats, see /sys/src/cmd/?l/asm.c for examples. There may be one there already that suits, or you can easily add another for your particular environment. But how do you separate out the constant data? On Mon Jan 30 23:36:55 EST 2006, noah.evans@gmail.com wrote: > Hey, quick 2l question. Is there any way to keep constant values in > ROM? If possible I'd like to keep the data section entirely in ROM > and only keep the BSS section in RAM. However, both sections seem to > be inextricably linked. > > What's the proper way to deal with this? > > Noah ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [9fans] Data segment vs BSS 2006-01-31 5:09 ` jmk @ 2006-01-31 5:35 ` Noah Evans 2006-01-31 5:48 ` jmk 0 siblings, 1 reply; 22+ messages in thread From: Noah Evans @ 2006-01-31 5:35 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Hmmmmm... it will require a lot of work understanding the linker, but if I end up running out of memory, I might see if I can get the const keyword to throw those variables in the text section and avoid the problem altogether. What do you think? Noah On 1/31/06, jmk@plan9.bell-labs.com <jmk@plan9.bell-labs.com> wrote: > The normal Plan 9 binary format assumes the BSS starts immediately > after the data, there is no place in the header to specify otherwise. > So, you want to use a different header format, e.g. ELF or one of > the machine-specific boot formats, see /sys/src/cmd/?l/asm.c for > examples. There may be one there already that suits, or you can easily > add another for your particular environment. > > But how do you separate out the constant data? > > On Mon Jan 30 23:36:55 EST 2006, noah.evans@gmail.com wrote: > > Hey, quick 2l question. Is there any way to keep constant values in > > ROM? If possible I'd like to keep the data section entirely in ROM > > and only keep the BSS section in RAM. However, both sections seem to > > be inextricably linked. > > > > What's the proper way to deal with this? > > > > Noah > ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [9fans] Data segment vs BSS 2006-01-31 5:35 ` Noah Evans @ 2006-01-31 5:48 ` jmk 2006-01-31 5:54 ` Ronald G Minnich 2006-01-31 9:03 ` Noah Evans 0 siblings, 2 replies; 22+ messages in thread From: jmk @ 2006-01-31 5:48 UTC (permalink / raw) To: 9fans The part of the loader for this is not dificult to understand. Grep for HEADTYPE in the source, only asm.c and obj.c will likely come up, and in each only one function: obj.c:main() sets up the variables that say where the virtual addresses of the sections are and asm.c:asmb() seeks around using those values for the different header types and writes the stuff out. Usually the data section has 2 types of data in it, constant data and data that can be modiied by the programme, how are you planning to separate those out? Many years ago when I did the boot ROM for the Hobbit boards I just copied the data to real memory so there was no issue like this. How big is your data segment, big enough to worry about using up RAM? On Tue Jan 31 00:36:11 EST 2006, noah.evans@gmail.com wrote: > Hmmmmm... it will require a lot of work understanding the linker, but > if I end up running out of memory, I might see if I can get the const > keyword to throw those variables in the text section and avoid the > problem altogether. > > What do you think? > > Noah > > > > On 1/31/06, jmk@plan9.bell-labs.com <jmk@plan9.bell-labs.com> wrote: > > The normal Plan 9 binary format assumes the BSS starts immediately > > after the data, there is no place in the header to specify otherwise. > > So, you want to use a different header format, e.g. ELF or one of > > the machine-specific boot formats, see /sys/src/cmd/?l/asm.c for > > examples. There may be one there already that suits, or you can easily > > add another for your particular environment. > > > > But how do you separate out the constant data? > > > > On Mon Jan 30 23:36:55 EST 2006, noah.evans@gmail.com wrote: > > > Hey, quick 2l question. Is there any way to keep constant values in > > > ROM? If possible I'd like to keep the data section entirely in ROM > > > and only keep the BSS section in RAM. However, both sections seem to > > > be inextricably linked. > > > > > > What's the proper way to deal with this? > > > > > > Noah > > ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [9fans] Data segment vs BSS 2006-01-31 5:48 ` jmk @ 2006-01-31 5:54 ` Ronald G Minnich 2006-01-31 8:48 ` Noah Evans ` (2 more replies) 2006-01-31 9:03 ` Noah Evans 1 sibling, 3 replies; 22+ messages in thread From: Ronald G Minnich @ 2006-01-31 5:54 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs jmk@plan9.bell-labs.com wrote: > Many years ago when I did the boot ROM for the Hobbit boards I just > copied the data to real memory so there was no issue like this. How > big is your data segment, big enough to worry about using up RAM? there is one other option. You can compress the data segment, and uncompress on loading. This will usually save a ton of space -- it's what we do on linuxbios, and the savings (surprise for me) really adds up. ron ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [9fans] Data segment vs BSS 2006-01-31 5:54 ` Ronald G Minnich @ 2006-01-31 8:48 ` Noah Evans 2006-01-31 15:03 ` Ronald G Minnich 2006-01-31 11:44 ` C H Forsyth 2006-01-31 12:39 ` Charles Forsyth 2 siblings, 1 reply; 22+ messages in thread From: Noah Evans @ 2006-01-31 8:48 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Maybe I should be a little more specific. I have a machine(a game boy advance) that only has 256k of memory but has a 32mb for rom. Basically I want to save every bit of RAM I can. Would your solution help? Noah On Jan 31, 2006, at 2:54 PM, Ronald G Minnich wrote: > jmk@plan9.bell-labs.com wrote: > >> Many years ago when I did the boot ROM for the Hobbit boards I just >> copied the data to real memory so there was no issue like this. How >> big is your data segment, big enough to worry about using up RAM? > > there is one other option. You can compress the data segment, and > uncompress on loading. This will usually save a ton of space -- > it's what we do on linuxbios, and the savings (surprise for me) > really adds up. > > ron ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [9fans] Data segment vs BSS 2006-01-31 8:48 ` Noah Evans @ 2006-01-31 15:03 ` Ronald G Minnich 2006-01-31 15:12 ` Noah Evans 0 siblings, 1 reply; 22+ messages in thread From: Ronald G Minnich @ 2006-01-31 15:03 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Noah Evans wrote: > Maybe I should be a little more specific. I have a machine(a game boy > advance) that only has 256k of memory but has a 32mb for rom. Basically > I want to save every bit of RAM I can. Would your solution help? > no. how much data will you save if it is rom, not ram. What are the addresses of rom and ram? contiguous? ron ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [9fans] Data segment vs BSS 2006-01-31 15:03 ` Ronald G Minnich @ 2006-01-31 15:12 ` Noah Evans 2006-01-31 16:05 ` Ronald G Minnich 0 siblings, 1 reply; 22+ messages in thread From: Noah Evans @ 2006-01-31 15:12 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs, Ronald G Minnich Nope unfortunately, RAM is: #define EWRAMZERO 0x02000000 #define EWRAMTOP 0x0203FFFF ROM starts at 0x08000000 On Feb 1, 2006, at 12:03 AM, Ronald G Minnich wrote: > Noah Evans wrote: >> Maybe I should be a little more specific. I have a machine(a game >> boy advance) that only has 256k of memory but has a 32mb for >> rom. Basically I want to save every bit of RAM I can. Would your >> solution help? > > no. how much data will you save if it is rom, not ram. What are the > addresses of rom and ram? contiguous? > > ron ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [9fans] Data segment vs BSS 2006-01-31 15:12 ` Noah Evans @ 2006-01-31 16:05 ` Ronald G Minnich 2006-01-31 16:11 ` Noah Evans 2006-01-31 16:24 ` Russ Cox 0 siblings, 2 replies; 22+ messages in thread From: Ronald G Minnich @ 2006-01-31 16:05 UTC (permalink / raw) To: Noah Evans; +Cc: Fans of the OS Plan 9 from Bell Labs Noah Evans wrote: > Nope unfortunately, RAM is: > > #define EWRAMZERO 0x02000000 > #define EWRAMTOP 0x0203FFFF > > ROM starts at 0x08000000 > Is it really worth all the work for 64k :-) ron ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [9fans] Data segment vs BSS 2006-01-31 16:05 ` Ronald G Minnich @ 2006-01-31 16:11 ` Noah Evans 2006-01-31 16:24 ` Russ Cox 1 sibling, 0 replies; 22+ messages in thread From: Noah Evans @ 2006-01-31 16:11 UTC (permalink / raw) To: Ronald G Minnich; +Cc: Fans of the OS Plan 9 from Bell Labs It's big brother has 4meg, but no emulator :-( Have to start somewhere :-) Noah On Feb 1, 2006, at 1:05 AM, Ronald G Minnich wrote: > Noah Evans wrote: >> Nope unfortunately, RAM is: >> #define EWRAMZERO 0x02000000 >> #define EWRAMTOP 0x0203FFFF >> ROM starts at 0x08000000 > > > Is it really worth all the work for 64k :-) > > ron ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [9fans] Data segment vs BSS 2006-01-31 16:05 ` Ronald G Minnich 2006-01-31 16:11 ` Noah Evans @ 2006-01-31 16:24 ` Russ Cox 2006-01-31 16:30 ` Paul Lalonde ` (2 more replies) 1 sibling, 3 replies; 22+ messages in thread From: Russ Cox @ 2006-01-31 16:24 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > Is it really worth all the work for 64k :-) Your comment makes it sound like he is working real hard to push 64k of data into the ROM, but that's not true. His situation is the opposite: he has megabytes of ROM but only 64k of data in which to work. In that case it may well be worth effort to get constant stuff into the huge ROM and save the miniscule RAM for actual data. Russ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [9fans] Data segment vs BSS 2006-01-31 16:24 ` Russ Cox @ 2006-01-31 16:30 ` Paul Lalonde 2006-01-31 16:52 ` C H Forsyth 2006-01-31 17:33 ` Ronald G Minnich 2 siblings, 0 replies; 22+ messages in thread From: Paul Lalonde @ 2006-01-31 16:30 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs As someone who works on these consoles for a living, am I ever glad the modern ones have real amounts of RAM and disk media. It's been a long time since I've had to worry about moving stuff to ROM. I have vague recollections of those days, but I've blotted them out as best I can. For oddness, though, over the last few days I've been writing object- file writing code - life is much better if you can adopt a binary file standard (even for your data, which is most of our case) that understands relocations natively, instead of some goobed up thing. But no-one's ELF libraries that I can find are anything except GPL viral. And the platform has a dynamic loader, so ELF it has to be. Paul On 31-Jan-06, at 8:24 AM, Russ Cox wrote: >> Is it really worth all the work for 64k :-) > > Your comment makes it sound like he is working real > hard to push 64k of data into the ROM, but that's not true. > > His situation is the opposite: he has megabytes of ROM > but only 64k of data in which to work. In that case it > may well be worth effort to get constant stuff into the > huge ROM and save the miniscule RAM for actual data. > > Russ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [9fans] Data segment vs BSS 2006-01-31 16:24 ` Russ Cox 2006-01-31 16:30 ` Paul Lalonde @ 2006-01-31 16:52 ` C H Forsyth 2006-01-31 17:33 ` Ronald G Minnich 2 siblings, 0 replies; 22+ messages in thread From: C H Forsyth @ 2006-01-31 16:52 UTC (permalink / raw) To: 9fans > His situation is the opposite: he has megabytes of ROM > but only 64k of data in which to work. In that case it > may well be worth effort to get constant stuff into the > huge ROM and save the miniscule RAM for actual data. for example, in one (inferno) kernel i tried this morning, 54k was strings; in another with a more typical set of modules, it was 128k! usually it doesn't matter because text and data are in the same physical space, but it does in his case. it seems quite a bit at first, but a `strings' on it looks reasonable. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [9fans] Data segment vs BSS 2006-01-31 16:24 ` Russ Cox 2006-01-31 16:30 ` Paul Lalonde 2006-01-31 16:52 ` C H Forsyth @ 2006-01-31 17:33 ` Ronald G Minnich 2 siblings, 0 replies; 22+ messages in thread From: Ronald G Minnich @ 2006-01-31 17:33 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Russ Cox wrote: > His situation is the opposite: he has megabytes of ROM > but only 64k of data in which to work. In that case it > may well be worth effort to get constant stuff into the > huge ROM and save the miniscule RAM for actual data. arg, I misread the situation ... sorry. ron ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [9fans] Data segment vs BSS 2006-01-31 5:54 ` Ronald G Minnich 2006-01-31 8:48 ` Noah Evans @ 2006-01-31 11:44 ` C H Forsyth 2006-01-31 12:06 ` Charles Forsyth 2006-01-31 12:39 ` Charles Forsyth 2006-01-31 12:39 ` Charles Forsyth 2 siblings, 2 replies; 22+ messages in thread From: C H Forsyth @ 2006-01-31 11:44 UTC (permalink / raw) To: 9fans [-- Attachment #1: Type: text/plain, Size: 1594 bytes --] that's the method i've used in a few bootstraps. a few left the kernel text in ROM uncompressed, to allow executing from there (usually with a significant speed penalty), but the data was decompressed into RAM. in the z[acl] suite for the 8-bit Atmel, we managed a small trick to reduce the RAM bill, because the SRAM was much smaller than flash. things such as radio parameters and audio processing tables were fairly big, but constant, and we needed RAM space for the FFT variables. the startup copies the initial contents of the writable data across and clears the bss. read-only values remain in program memory (flash). the compiler would put any unmodified data declared static into program memory. const was not needed: the compiler did the analysis. it was harder than it sounds because the program memory requires different instructions to read it, a little worse than plain `separate I&D addressing'. the linker had a little more work to do, but more important, the compiler had to ensure that no data was marked for program memory until it had checked that it was never accessed indirectly (because then the called function would use the wrong instruction). again, const would not have been accurate enough. unfortunately, the technique couldn't be used for strings, on that processor, because functions such as str*, mem*, print, etc. are used with sources that can be either readonly or writable. on the ARM, though, the compiler could put strings in the text segment easily enough; it might do that already, but i can't remember and i'll need to check. [-- Attachment #2: Type: message/rfc822, Size: 3218 bytes --] From: Ronald G Minnich <rminnich@lanl.gov> To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: Re: [9fans] Data segment vs BSS Date: Mon, 30 Jan 2006 22:54:15 -0700 Message-ID: <43DEFB87.7040806@lanl.gov> jmk@plan9.bell-labs.com wrote: > Many years ago when I did the boot ROM for the Hobbit boards I just > copied the data to real memory so there was no issue like this. How > big is your data segment, big enough to worry about using up RAM? there is one other option. You can compress the data segment, and uncompress on loading. This will usually save a ton of space -- it's what we do on linuxbios, and the savings (surprise for me) really adds up. ron ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [9fans] Data segment vs BSS 2006-01-31 11:44 ` C H Forsyth @ 2006-01-31 12:06 ` Charles Forsyth 2006-01-31 12:39 ` Charles Forsyth 1 sibling, 0 replies; 22+ messages in thread From: Charles Forsyth @ 2006-01-31 12:06 UTC (permalink / raw) To: 9fans > more important, the compiler had to ensure that no data was marked for program > memory until it had checked that it was never accessed indirectly (because > then the called function would use the wrong instruction). again, const sorry, i meant `indirectly by something that might access both forms of data'. for instance, it allowed a table's address to be taken by p = &table (or plain p = table for an array) and tracked that nothing was assigned through p, and that p was not assigned elsewhere to point to writable data. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [9fans] Data segment vs BSS 2006-01-31 11:44 ` C H Forsyth 2006-01-31 12:06 ` Charles Forsyth @ 2006-01-31 12:39 ` Charles Forsyth 2006-01-31 13:06 ` Noah Evans 1 sibling, 1 reply; 22+ messages in thread From: Charles Forsyth @ 2006-01-31 12:39 UTC (permalink / raw) To: 9fans > on the ARM, though, the compiler could > put strings in the text segment easily enough i really meant the linker, but never mind. it misses a trick and doesn't do it by default. the -t option enables it, but in the Inferno 5l that does thumb as well, that sadly enables some debugging (`t'humb). silly oversight. fixed. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [9fans] Data segment vs BSS 2006-01-31 12:39 ` Charles Forsyth @ 2006-01-31 13:06 ` Noah Evans 2006-01-31 13:44 ` Charles Forsyth 0 siblings, 1 reply; 22+ messages in thread From: Noah Evans @ 2006-01-31 13:06 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Cool. Can you send me the fix via private mail? After reading the 9fans responses, I have a better handle on the problem. After a reading of a.out(10.6) I realized that I might have to use a bootstrap loader. Right now I'm just reading the rom directly from text(the GBA typically runs all of it's programs from rom) and there's no header(the gba needs a special rom header starting from 0x0, otherwise it won't boot). It makes it to main just fine, but no header is causing havoc with the data and bss sections. How are edata and end defined by the linker? You can't redefine them from your code, but given the current state of my code, if I could just intuit and change where the program thinks the data and bss are, it would be easy enough to memcpy them from rom where they need to go. Regarding the program and memory, I'm looking at: ksize igba.gba 359928t + 90992d + 54936b = 505856 igba.gba which should halfway work. Noah On 1/31/06, Charles Forsyth <forsyth@terzarima.net> wrote: > > on the ARM, though, the compiler could > > put strings in the text segment easily enough > > i really meant the linker, but never mind. it misses a trick and doesn't do it > by default. the -t option enables it, but in the Inferno 5l that does thumb > as well, that sadly enables some debugging (`t'humb). silly oversight. > fixed. > > ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [9fans] Data segment vs BSS 2006-01-31 13:06 ` Noah Evans @ 2006-01-31 13:44 ` Charles Forsyth 0 siblings, 0 replies; 22+ messages in thread From: Charles Forsyth @ 2006-01-31 13:44 UTC (permalink / raw) To: 9fans > Cool. Can you send me the fix via private mail? i've done that. also how to declare and use edata, -D etc to get the right effect. i'd have sent it to the list but we might as well check it by experiment before doing that, since i might have got some points a little wrong, such as who rounds what when, even though i've just looked at the code. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [9fans] Data segment vs BSS 2006-01-31 5:54 ` Ronald G Minnich 2006-01-31 8:48 ` Noah Evans 2006-01-31 11:44 ` C H Forsyth @ 2006-01-31 12:39 ` Charles Forsyth 2006-01-31 15:05 ` Ronald G Minnich 2 siblings, 1 reply; 22+ messages in thread From: Charles Forsyth @ 2006-01-31 12:39 UTC (permalink / raw) To: 9fans > This will usually save a ton of space -- it's > what we do on linuxbios, and the savings (surprise for me) really adds up. i was quite surprised how much SRAM on the atmel was occupied by string literals, so traces and diagnostics quickly became terse; still using letters not error numbers, though, so as not to confuse data with disaster. i suppose it wouldn't, however, be string literals in linuxbios because gcc (i thought) tags them for rom. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [9fans] Data segment vs BSS 2006-01-31 12:39 ` Charles Forsyth @ 2006-01-31 15:05 ` Ronald G Minnich 0 siblings, 0 replies; 22+ messages in thread From: Ronald G Minnich @ 2006-01-31 15:05 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Charles Forsyth wrote: >>This will usually save a ton of space -- it's >>what we do on linuxbios, and the savings (surprise for me) really adds up. > > > i was quite surprised how much SRAM on the atmel was occupied > by string literals, so traces and diagnostics quickly became terse; > still using letters not error numbers, though, so as not to > confuse data with disaster. i suppose it wouldn't, however, be string literals > in linuxbios because gcc (i thought) tags them for rom. > actually, it is a lot of ldscript hackery that drives me nuts. ron ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [9fans] Data segment vs BSS 2006-01-31 5:48 ` jmk 2006-01-31 5:54 ` Ronald G Minnich @ 2006-01-31 9:03 ` Noah Evans 1 sibling, 0 replies; 22+ messages in thread From: Noah Evans @ 2006-01-31 9:03 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Depending on how things end up I may get in there and start mucking around. Your advice is greatly appreciated. The data section is pretty small now, something like 64 bytes(this is entirely a guesstimate based on the value of the pointer to edata, is bdata defined on 5l? I'm getting an undefined error if I try to use it), but I'm assuming as I get more and more of Inferno functioning this will get bigger. What I'm thinking of doing regarding differentiating the immutable data is to use to symbol const to mark immutable data. Anything marked const would go in the text section, anything else would go to the data section. But right now all of this is just speculation. I need to get the lcd before anything else. Noah On Jan 31, 2006, at 2:48 PM, jmk@plan9.bell-labs.com wrote: > s is not dificult to understand. > Grep for HEADTYPE in the source, only asm.c and obj.c will likely > come up, and in each only one function: obj.c:main() sets up the > variables that say where the virtual addresses of the sections are > and asm.c:asmb() seeks around using those values for the different > header types and writes the stuff out. > > Usually the data section has 2 types of data in it, constant data > and data that can be modiied by the programme, how are you planning > to separate those out? > ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2006-01-31 17:33 UTC | newest] Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-01-31 4:36 [9fans] Data segment vs BSS Noah Evans 2006-01-31 5:09 ` jmk 2006-01-31 5:35 ` Noah Evans 2006-01-31 5:48 ` jmk 2006-01-31 5:54 ` Ronald G Minnich 2006-01-31 8:48 ` Noah Evans 2006-01-31 15:03 ` Ronald G Minnich 2006-01-31 15:12 ` Noah Evans 2006-01-31 16:05 ` Ronald G Minnich 2006-01-31 16:11 ` Noah Evans 2006-01-31 16:24 ` Russ Cox 2006-01-31 16:30 ` Paul Lalonde 2006-01-31 16:52 ` C H Forsyth 2006-01-31 17:33 ` Ronald G Minnich 2006-01-31 11:44 ` C H Forsyth 2006-01-31 12:06 ` Charles Forsyth 2006-01-31 12:39 ` Charles Forsyth 2006-01-31 13:06 ` Noah Evans 2006-01-31 13:44 ` Charles Forsyth 2006-01-31 12:39 ` Charles Forsyth 2006-01-31 15:05 ` Ronald G Minnich 2006-01-31 9:03 ` Noah Evans
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).