* Autoincrement addressing modes @ 1998-02-11 18:20 Michael P. Hayes 1998-02-11 16:33 ` Joern Rennecke 1998-02-12 6:42 ` Richard Henderson 0 siblings, 2 replies; 16+ messages in thread From: Michael P. Hayes @ 1998-02-11 18:20 UTC (permalink / raw) To: gcc2, egcs I have been working on generalised support for autoincrement addressing modes, where the increment may be a constant (not just the width of the data type), an index register, or even potentially a scaled index register, circularly modified base register, or bit-reversed base register. The format I've used is: (post_modify (reg base) (expr)) (pre_modify (reg base) (expr)) where in the first case (reg base) is used as the address and then this gets set to (expr) and in the second case (reg base) gets set to (expr) and then used as the address. Currently, I've patched flow.c and reload.c to handle the common forms: ({post,pre}_modify (reg base) (plus (reg base) (reg index))) ({post,pre}_modify (reg base) (plus (reg base) (const_int))) ({post,pre}_modify (reg base) (minus (reg base) (reg index))) supporting addressing modes such as: *(base += index) *(base += const) *(base -= index) At this stage I'm interested in what other common forms should be supported. I'm also wondering if it is worthwhile to describe the addressing modes of a machine, using something like: (define_address [(mem:SF (match_operand:SI 0 "base_register" "a"))] "" "*%0") or (define_address [(mem:SI (plus:SI (match_operand:SI 0 "base_register" "a") (match_operand:SI 1 "index_register" "x")))] "" "*%0(%1)") or (define_address [(mem:SI (post_modify:SI (match_operand:SI 0 "base_register" "a") (plus:SI (match_dup 0) (match_operand:SI 1 "index_register" "x"))))] "" "*%0++(%1)") ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Autoincrement addressing modes 1998-02-11 18:20 Autoincrement addressing modes Michael P. Hayes @ 1998-02-11 16:33 ` Joern Rennecke 1998-02-11 17:22 ` Jeffrey A Law 1998-02-12 6:42 ` Richard Henderson 1 sibling, 1 reply; 16+ messages in thread From: Joern Rennecke @ 1998-02-11 16:33 UTC (permalink / raw) To: Michael P. Hayes; +Cc: gcc2, egcs > At this stage I'm interested in what other common forms should be > supported. The SH doesn't have any exotic update forms, but it has another quirk in autoincrement that gcc doesn't handle efficiently: POST_INC is only available for reading, while PRE_DEC is only available for writing. There are some places in the compiler that just test POST_INC / PRE_DEC (or more generally HAVE_AUTO_INC) to check if an autoincrement might be generated in a later stage. It would be nice if these would be updated not only to handle the new address updates properly, but also only speculate the appropriatenes of an address update depending on the direction of the memory access. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Autoincrement addressing modes 1998-02-11 16:33 ` Joern Rennecke @ 1998-02-11 17:22 ` Jeffrey A Law 1998-02-11 17:22 ` Michael P. Hayes 0 siblings, 1 reply; 16+ messages in thread From: Jeffrey A Law @ 1998-02-11 17:22 UTC (permalink / raw) To: Joern Rennecke; +Cc: Michael P. Hayes, gcc2, egcs In message < 199802112304.XAA11969@phal.cygnus.co.uk >you write: > > At this stage I'm interested in what other common forms should be > > supported. > > The SH doesn't have any exotic update forms, but it has another > quirk in autoincrement that gcc doesn't handle efficiently: > POST_INC is only available for reading, while PRE_DEC is only > available for writing. The PA has similar constraints. jeff ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Autoincrement addressing modes 1998-02-11 17:22 ` Jeffrey A Law @ 1998-02-11 17:22 ` Michael P. Hayes 1998-02-11 16:33 ` Joern Rennecke ` (2 more replies) 0 siblings, 3 replies; 16+ messages in thread From: Michael P. Hayes @ 1998-02-11 17:22 UTC (permalink / raw) To: law; +Cc: Joern Rennecke, Michael P. Hayes, gcc2, egcs Jeffrey A Law writes: > > In message < 199802112304.XAA11969@phal.cygnus.co.uk >you write: > > > At this stage I'm interested in what other common forms should be > > > supported. > > > > The SH doesn't have any exotic update forms, but it has another > > quirk in autoincrement that gcc doesn't handle efficiently: > > POST_INC is only available for reading, while PRE_DEC is only > > available for writing. > The PA has similar constraints. Does this asymmetry only apply to these update forms of addressing modes? Any ideas how to describe this to GCC? I suppose if there was a flag to differentiate memory reads from writes, then GO_IF_LEGITIMATE_ADDRESS could reject the invalid forms. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Autoincrement addressing modes 1998-02-11 17:22 ` Michael P. Hayes @ 1998-02-11 16:33 ` Joern Rennecke 1998-02-11 18:20 ` Jeffrey A Law 1998-02-11 18:20 ` Joern Rennecke 2 siblings, 0 replies; 16+ messages in thread From: Joern Rennecke @ 1998-02-11 16:33 UTC (permalink / raw) To: Michael P. Hayes; +Cc: law, amylaar, michaelh, gcc2, egcs > Does this asymmetry only apply to these update forms of addressing > modes? The SH only has POST_INC and PRE_DEC. I don't know what asymmetries appear in other processors, though. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Autoincrement addressing modes 1998-02-11 17:22 ` Michael P. Hayes 1998-02-11 16:33 ` Joern Rennecke @ 1998-02-11 18:20 ` Jeffrey A Law 1998-02-11 18:20 ` Joern Rennecke 2 siblings, 0 replies; 16+ messages in thread From: Jeffrey A Law @ 1998-02-11 18:20 UTC (permalink / raw) To: Michael P. Hayes; +Cc: Joern Rennecke, gcc2, egcs In message < 199802120014.NAA29645@ongaonga.chch.cri.nz >you write: > > The PA has similar constraints. > > Does this asymmetry only apply to these update forms of addressing > modes? Well, there's some weird asymmetry problems with nearly all of the addressing modes, except for (reg) on the PA. Many we are able to ignore, others we deal with by not considering such addresses valid according to GO_IF_LEGITIMATE_ADDRESS -- we do allow them in some predicates when we can check for the weird problems. > Any ideas how to describe this to GCC? I suppose if there was a flag > to differentiate memory reads from writes, then > GO_IF_LEGITIMATE_ADDRESS could reject the invalid forms. So far we haven't tried. Being able to distinguish between loads & stores in GO_IF_LEG... would be a big step forward, but a lot of work. My recommendation would be to not try and handle *all* the cases in the first submission. Just get something that can be extended, particularly if we do fix GO_IF_LEG... later. jeff ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Autoincrement addressing modes 1998-02-11 17:22 ` Michael P. Hayes 1998-02-11 16:33 ` Joern Rennecke 1998-02-11 18:20 ` Jeffrey A Law @ 1998-02-11 18:20 ` Joern Rennecke 2 siblings, 0 replies; 16+ messages in thread From: Joern Rennecke @ 1998-02-11 18:20 UTC (permalink / raw) To: Michael P. Hayes; +Cc: law, amylaar, michaelh, gcc2, egcs > Does this asymmetry only apply to these update forms of addressing > modes? > > Any ideas how to describe this to GCC? I suppose if there was a flag One way would be to have HAVE_PRE_DECREMENT_READ and HAVE_PRE_DECREMENT_WRITE to control the two possible uses of PRE_DEC; when HAVE_PRE_DECREMENT is defined, it can mean both of the above, to maintain backward compatibility and make it easy for ports that don't need to distinguish them. Similarily for POST_DEC, PRE_INC, POST_INC. > to differentiate memory reads from writes, then > GO_IF_LEGITIMATE_ADDRESS could reject the invalid forms. That would be goof too, but it doesn't help the code that doesn't actually try to use the auto-increment, e.g. like move_by_pieces in expr.c ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Autoincrement addressing modes 1998-02-11 18:20 Autoincrement addressing modes Michael P. Hayes 1998-02-11 16:33 ` Joern Rennecke @ 1998-02-12 6:42 ` Richard Henderson 1998-02-14 15:24 ` Michael P. Hayes 1998-03-16 20:25 ` Joern Rennecke 1 sibling, 2 replies; 16+ messages in thread From: Richard Henderson @ 1998-02-12 6:42 UTC (permalink / raw) To: Michael P. Hayes; +Cc: egcs On Thu, Feb 12, 1998 at 11:06:26AM +1300, Michael P. Hayes wrote: > I'm also wondering if it is worthwhile to describe the addressing > modes of a machine, using something like: > > (define_address > [(mem:SF (match_operand:SI 0 "base_register" "a"))] > "" > "*%0") I think this is a swell idea. I can see it as being particularly useful to use this kind of description to help auto-generate GO_IF_LEGITIMATE_ADDRESS and LEGITIMIZE_ADDRESS. As it is not a few ports lie to gcc about how addresses really work with -fpic, perhaps if it were easier to describe, ports would quite lying. Though I would get rid of the mem and add a name, (define_address "base_disp" [(plus:DI (match_operand:DI 0 "register_operand" "r") (match_operand:DI 1 "const16_operand" "I"))] "" "%1(%0)") (define_address "unaligned_base_disp" [(and:DI (plus:DI (match_operand:DI 0 "register_operand" "r") (match_operand:DI 1 "const16_operand" "I")) (const_int -8))] "" "%1(%0)") (define_address "symbolic" [(match_operand:SI 0 "symbolic_operand" "s")] "! flag_pic" "%0") (define_address "symbolic" [(plus:SI (reg:SI "ebx") (match_operand:SI 0 "symbolic_operand" "s"))] "flag_pic" "%0(%%ebx)") and create a mechanism whereby related address modes could be collected and named ("input_address"). You might also allow addressing modes to be given attributes, like "cost" or "length". The former might be useful in creating ADDRESS_COST, the later in adjusting the length of the insn that contains the address. It would be interesting to see what would happen if the mov insns were restructured to name the precise address modes that could be used (via a match_address). This would increase the number of insn patterns, possibly greatly, but it would also allow all the HAVE_PRE_DEC_INPUT or whatever uglyness to be detected by genconfig. Just rambling at this point... r~ ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Autoincrement addressing modes 1998-02-12 6:42 ` Richard Henderson @ 1998-02-14 15:24 ` Michael P. Hayes 1998-03-16 20:25 ` Joern Rennecke 1 sibling, 0 replies; 16+ messages in thread From: Michael P. Hayes @ 1998-02-14 15:24 UTC (permalink / raw) To: Richard Henderson; +Cc: Michael P. Hayes, egcs Richard Henderson writes: > On Thu, Feb 12, 1998 at 11:06:26AM +1300, Michael P. Hayes wrote: > > I'm also wondering if it is worthwhile to describe the addressing > > modes of a machine, using something like: > > > > (define_address > > [(mem:SF (match_operand:SI 0 "base_register" "a"))] > > "" > > "*%0") > > I think this is a swell idea. I can see it as being particularly > useful to use this kind of description to help auto-generate > GO_IF_LEGITIMATE_ADDRESS and LEGITIMIZE_ADDRESS. As it is not a > few ports lie to gcc about how addresses really work with -fpic, > perhaps if it were easier to describe, ports would quite lying. > > Though I would get rid of the mem and add a name, Yes, I agree. Initially I thought that it was necessary to specify the mode that could be addressed (say to validate an offsettable displacement), but this should be handled by the condition. This condition could also test a global variable, memory_read, or some such thing, to handle the assymetry of some machines where autoincrements are OK for memory reads but not for memory writes. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Autoincrement addressing modes 1998-02-12 6:42 ` Richard Henderson 1998-02-14 15:24 ` Michael P. Hayes @ 1998-03-16 20:25 ` Joern Rennecke 1998-03-16 20:25 ` Richard Henderson 1998-03-16 20:44 ` Michael P. Hayes 1 sibling, 2 replies; 16+ messages in thread From: Joern Rennecke @ 1998-03-16 20:25 UTC (permalink / raw) To: rth; +Cc: michaelh, egcs > > (define_address > > [(mem:SF (match_operand:SI 0 "base_register" "a"))] > > "" > > "*%0") > > I think this is a swell idea. I can see it as being particularly > useful to use this kind of description to help auto-generate > GO_IF_LEGITIMATE_ADDRESS and LEGITIMIZE_ADDRESS. As it is not a > few ports lie to gcc about how addresses really work with -fpic, > perhaps if it were easier to describe, ports would quite lying. > > Though I would get rid of the mem and add a name, > > (define_address "base_disp" > [(plus:DI (match_operand:DI 0 "register_operand" "r") > (match_operand:DI 1 "const16_operand" "I"))] > "" > "%1(%0)") Adding a name is fine, but I wouldn't want to drop the mem. Note that the mem has a mode, which is useful for a number of ports. If it is not useful, you can still leave out the mode (i.e., it will be VoidMODE). moreover, we need some way to link the address forms to the places where they are possible - e.g. it is common that the set of allowed addresses for loads is different from the ones allowed for stores. Should that be a list of constraints - e.g. "g" could be only for reading general operands, "=g" only for writing general operands, "=g,g" for either of these, "+g" only for read-write general operands, "=" for and kind of write-only operand... Or should we put lists of addressing modes in some other kind of declaration in the machine description? E.g.: (define_load ["base", "base_disp", "auto_inc"]) (define_store ["base", "base_disp", "auto_dec"]) (define_mem_arith ["base", "base_disp"]) ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Autoincrement addressing modes 1998-03-16 20:25 ` Joern Rennecke @ 1998-03-16 20:25 ` Richard Henderson 1998-03-16 20:25 ` Michael P. Hayes 1998-03-16 20:44 ` Michael P. Hayes 1 sibling, 1 reply; 16+ messages in thread From: Richard Henderson @ 1998-03-16 20:25 UTC (permalink / raw) To: Joern Rennecke; +Cc: rth, michaelh, egcs On Mon, Mar 16, 1998 at 10:51:27PM +0000, Joern Rennecke wrote: > Adding a name is fine, but I wouldn't want to drop the mem. Note that the > mem has a mode, which is useful for a number of ports. > If it is not useful, you can still leave out the mode (i.e., it will be > VoidMODE). > > moreover, we need some way to link the address forms to the places where > they are possible - e.g. it is common that the set of allowed addresses > for loads is different from the ones allowed for stores. I thought I'd had a pseudo example of what I'd had in mind for handling both of these in a stroke: referencing it in an insn. (define_insn "*movsi_load" [(set (match_operand:SI 0 "register_operand" "r") (mem:SI (match_address:PI 1 "base,base_disp,auto_inc")))] "ldl %0,%1") (define_insn "*movsi_store" [(set (mem:SI (match_address:PI 1 "base,base_disp,auto_dec")) (match_operand:SI 0 "register_operand" "r"))] "stl %0,%1") (While we're at changes, recognize PI as an alias for SI or DI as appropriate to the current pointer size.) I like this method since it allows to use the same address forms in lea-type instructions. We'll also probably find it convenient to do something similar to (define_address "load" ["base", "base_disp", "auto_inc"]) simply to define aliases that are combinations of address types, since otherwise cisc-y boxes like i386 and m68k will get unwieldy. r~ ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Autoincrement addressing modes 1998-03-16 20:25 ` Richard Henderson @ 1998-03-16 20:25 ` Michael P. Hayes 1998-03-16 20:25 ` Joern Rennecke 0 siblings, 1 reply; 16+ messages in thread From: Michael P. Hayes @ 1998-03-16 20:25 UTC (permalink / raw) To: Richard Henderson; +Cc: Joern Rennecke, michaelh, egcs Richard Henderson writes: > On Mon, Mar 16, 1998 at 10:51:27PM +0000, Joern Rennecke wrote: > I thought I'd had a pseudo example of what I'd had in mind for handling > both of these in a stroke: referencing it in an insn. > > (define_insn "*movsi_load" > [(set (match_operand:SI 0 "register_operand" "r") > (mem:SI (match_address:PI 1 "base,base_disp,auto_inc")))] > "ldl %0,%1") > > (define_insn "*movsi_store" > [(set (mem:SI (match_address:PI 1 "base,base_disp,auto_dec")) > (match_operand:SI 0 "register_operand" "r"))] > "stl %0,%1") > I'm unsure about this since it would require wholesale changes to the machine description. For example, how would you handle an add insn that could have memory or register operands in various combinations? > (While we're at changes, recognize PI as an alias for SI or DI as > appropriate to the current pointer size.) I agree that Pmode should be used for addresses in the machine description. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Autoincrement addressing modes 1998-03-16 20:25 ` Michael P. Hayes @ 1998-03-16 20:25 ` Joern Rennecke 1998-03-17 1:28 ` Richard Henderson 0 siblings, 1 reply; 16+ messages in thread From: Joern Rennecke @ 1998-03-16 20:25 UTC (permalink / raw) To: Michael P. Hayes; +Cc: rth, amylaar, michaelh, egcs > > I thought I'd had a pseudo example of what I'd had in mind for handling > > both of these in a stroke: referencing it in an insn. > > > > (define_insn "*movsi_load" > > [(set (match_operand:SI 0 "register_operand" "r") > > (mem:SI (match_address:PI 1 "base,base_disp,auto_inc")))] > > "ldl %0,%1") > > > > (define_insn "*movsi_store" > > [(set (mem:SI (match_address:PI 1 "base,base_disp,auto_dec")) > > (match_operand:SI 0 "register_operand" "r"))] > > "stl %0,%1") > > > > I'm unsure about this since it would require wholesale changes to the > machine description. For example, how would you handle an add insn > that could have memory or register operands in various combinations? Seconded. This even applies to some RISC pattern, e.g. sign/zero extension can be a register-register operation or a memory-register operation. The way gcc is designde we have to use a single pattern for this so that reload can do The Right Thing (tm). ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Autoincrement addressing modes 1998-03-16 20:25 ` Joern Rennecke @ 1998-03-17 1:28 ` Richard Henderson 1998-03-17 13:29 ` Joern Rennecke 0 siblings, 1 reply; 16+ messages in thread From: Richard Henderson @ 1998-03-17 1:28 UTC (permalink / raw) To: Joern Rennecke; +Cc: Michael P. Hayes, rth, egcs > Seconded. This even applies to some RISC pattern, e.g. sign/zero extension > can be a register-register operation or a memory-register operation. > The way gcc is designde we have to use a single pattern for this so that > reload can do The Right Thing (tm). Good point. Perhaps the thing to do then is to tie addresses to instruction types, a-la (define_attr "type" "ld,st,lea") (define_address "base" (mem (match_operand:PI 0 "register_operand" "r")) (eq_attr "type" "ld,st,lea") "0(%0)") (define_address "auto_inc" (mem (post_inc (match_operand:PI 0 "register_operand" "r"))) (eq_attr "type" "ld") "(%0)+") This would then let us have arbitrarily complex conditions that the insn must satisfy before the address strictly matches. Not sure exactly how we'd notice that insn type "ist" is a store, for early (pre-reload) optimizations for things like auto_inc. Perhaps with magic attributes on the addresses themselves, though it would be nicer to discover these kinds of things rather than having to be told. r~ ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Autoincrement addressing modes 1998-03-17 1:28 ` Richard Henderson @ 1998-03-17 13:29 ` Joern Rennecke 0 siblings, 0 replies; 16+ messages in thread From: Joern Rennecke @ 1998-03-17 13:29 UTC (permalink / raw) To: rth; +Cc: amylaar, michaelh, rth, egcs > Good point. Perhaps the thing to do then is to tie addresses > to instruction types, a-la > > (define_attr "type" "ld,st,lea") > > (define_address "base" > (mem (match_operand:PI 0 "register_operand" "r")) > (eq_attr "type" "ld,st,lea") > "0(%0)") > > (define_address "auto_inc" > (mem (post_inc (match_operand:PI 0 "register_operand" "r"))) > (eq_attr "type" "ld") > "(%0)+") > > This would then let us have arbitrarily complex conditions that > the insn must satisfy before the address strictly matches. We already have this possibility when recognizing an insn - since every insn can have an arbitrary condition. Thus, if we actually need to have the exact insn in order to verify it, we win nothing compared to the current scheme. One possible improvement could be if we don't need to have the exact insn, but only one that matches the right pattern, and then be able to look at the different alternatives 'by hand' . If we make the "type" attribute 'magic', we could probably do some tests for possible addressing modes without actually modifying the insn - provided that the "type" attribute of the insn only depends on the alternative, and that the conditions of the addressing modes are NOT arbitrarily complex, but only list a list of possible insn types. > Not sure exactly how we'd notice that insn type "ist" is a store, > for early (pre-reload) optimizations for things like auto_inc. > Perhaps with magic attributes on the addresses themselves, though > it would be nicer to discover these kinds of things rather than > having to be told. That is not that hard in flow / regmove when we are dealing with actual insns, but it seems near impossible for pre-rtl-generation tests like in expr.c:move_by_pieces . We probably have to use some sort of approximation, i.e. if the mode & direction is available for any insn & alternative under some condition, we presume that it is available. But if using predicates that the gen* files don't understand will lead to poor code, maybe we should not use a model that encourages to use them. To pick up the example from above, we could say: (define_address "base" (mem (match_operand:PI 0 "register_operand" "r")) "ld,st,lea" "0(%0)") and it is implied that "ld,st,lea" is a list of values for the attribute "type" . If addressing modes of different operands interfere with each other, it should in general be possible to express this with sufficiently detailed instruction alternatives. If you need anything more complicated, it should propably go into the insn predicate. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Autoincrement addressing modes 1998-03-16 20:25 ` Joern Rennecke 1998-03-16 20:25 ` Richard Henderson @ 1998-03-16 20:44 ` Michael P. Hayes 1 sibling, 0 replies; 16+ messages in thread From: Michael P. Hayes @ 1998-03-16 20:44 UTC (permalink / raw) To: Joern Rennecke; +Cc: rth, michaelh, egcs Joern Rennecke writes: > Adding a name is fine, but I wouldn't want to drop the mem. Note that the > mem has a mode, which is useful for a number of ports. > If it is not useful, you can still leave out the mode (i.e., it will be > VoidMODE). I think I like having the mem since it does indicate which modes are valid for the address (although it could be handled by an extra condition). If the mem was kept, this define_address construct could be generalised to something like define_operand which could detail all the valid operand forms for the target machine. I would also like to see a more generalised cost mechanism for operands that takes into account other operands used in an insn. For example, a small immediate integer may have a low cost in an insn if the other operand is a register, but a high cost if the other operand is a memory address. > moreover, we need some way to link the address forms to the places where > they are possible - e.g. it is common that the set of allowed addresses > for loads is different from the ones allowed for stores. The problem here is dealing with insns that may allow two addresses with small displacements but only one address with a large displacement. I suppose the only way to be sure that an address is valid for an insn is to try recognising the insn with that address. I've had similar problems (notably with instantiate_virtual_regs_1) where a small constant is added to an address. While the new address is deemed valid by memory_address_p, it is no longer valid for the insn it is used with. ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~1998-03-17 13:29 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1998-02-11 18:20 Autoincrement addressing modes Michael P. Hayes 1998-02-11 16:33 ` Joern Rennecke 1998-02-11 17:22 ` Jeffrey A Law 1998-02-11 17:22 ` Michael P. Hayes 1998-02-11 16:33 ` Joern Rennecke 1998-02-11 18:20 ` Jeffrey A Law 1998-02-11 18:20 ` Joern Rennecke 1998-02-12 6:42 ` Richard Henderson 1998-02-14 15:24 ` Michael P. Hayes 1998-03-16 20:25 ` Joern Rennecke 1998-03-16 20:25 ` Richard Henderson 1998-03-16 20:25 ` Michael P. Hayes 1998-03-16 20:25 ` Joern Rennecke 1998-03-17 1:28 ` Richard Henderson 1998-03-17 13:29 ` Joern Rennecke 1998-03-16 20:44 ` Michael P. Hayes
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 read-only IMAP folder(s) and NNTP newsgroup(s).