tvf@frau.UUCP (Thomas V. Frauenhofer) (02/04/90)
Has anyone ported C-news to Microport V/AT? I have the entire C-news source (last patch date: Jan 10, 1990) and would like to get it running on my system, but I'm not inclined to re-invent the wheel if someone else has done it already. Thanks in advance! -- Thomas V. Frauenhofer ...!rutgers!rochester!cci632!ccird7!frau!tvf *or* ...!attctc!swamps!frau!tvf (tvf@frau, tvf@cci632) Daffy Duck Sings: "I once knew an acrobat's daughter who swung by her teeth from a noose. 'Til one day her bridgework gave way, and she flew through the air like a Goose!"
" Maynard) (02/07/90)
In article <45@frau.UUCP> tvf@frau.UUCP (0000-Thomas V. Frauenhofer) writes: >Has anyone ported C-news to Microport V/AT? I have the entire C-news source >(last patch date: Jan 10, 1990) and would like to get it running on my >system, but I'm not inclined to re-invent the wheel if someone else has done >it already. Yes, it can be made to run. It's not simple. In particular, expire and relaynews need to be compiled in large model, or else they run out of memory. Unfortunately, there are pieces of the code that cause compiler internal errors when compiled large model, so you can't just build the whole thing in large model; you have to build it all in small model, then go back and manually build expire and relaynews. I strongly recmmend using dbz with it. It speeds things up tremendously. Forget about the INCORE option, though. There are some replacement/enhancement programs that Jon Zeeff wrote that do very well, too. There's one macro that needs to be simplified to make Microport's compiler happy: In relay/hdrdefs.c, the definition of the offsetof() macro needs to be changed to #define offsetof(type, mem) ((int)&((type *)NULL)->mem) That's all that immediately springs to mind; if you run into any problems, feel free to email me, and I'll try to help. -- Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can jay@splut.conmicro.com (eieio)| adequately be explained by stupidity. {attctc,bellcore}!texbell!splut!jay +---------------------------------------- Free the DC-10!
henry@utzoo.uucp (Henry Spencer) (02/09/90)
In article <3+1:A3-@splut.conmicro.com> jay@splut.conmicro.com (Jay "you ignorant splut!" Maynard) writes: >>Has anyone ported C-news to Microport V/AT? ... > >It's not simple. In particular, expire and relaynews need to be compiled >in large model, or else they run out of memory... I'm a bit surprised at that, as they do run on 16-bit machines, but this is somewhat a function of things like how many groups you get. If your active file is 28KB (like ours), this clearly raises storm warnings for 16-bit programs that want to keep it all in core. >There's one macro that needs to be simplified to make Microport's >compiler happy: In relay/hdrdefs.c, the definition of the offsetof() >macro needs to be changed to >#define offsetof(type, mem) ((int)&((type *)NULL)->mem) This is now discussed in notebook/problems, along with other porting problems of various kinds. -- SVR4: every feature you ever | Henry Spencer at U of Toronto Zoology wanted, and plenty you didn't.| uunet!attcan!utzoo!henry henry@zoo.toronto.edu
" Maynard) (02/11/90)
In article <1990Feb8.182437.25095@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >In article <3+1:A3-@splut.conmicro.com> jay@splut.conmicro.com (Jay "you ignorant splut!" Maynard) writes: >>>Has anyone ported C-news to Microport V/AT? ... >>It's not simple. In particular, expire and relaynews need to be compiled >>in large model, or else they run out of memory... >I'm a bit surprised at that, as they do run on 16-bit machines, but this >is somewhat a function of things like how many groups you get. If your >active file is 28KB (like ours), this clearly raises storm warnings for >16-bit programs that want to keep it all in core. Well, they run...but they fail in the middle. Expire complains about running out of memory, sometimes saying that it's trying to read a line of history, sometimes not; relaynews simply fails mysteriously. My active file: -rw-rw-r-- 1 usenet news 20865 Feb 10 15:50 /usr/lib/news/active Not huge, but not trivial, either. Unfortunately, rebuilding just expire and relaynews in large model is such a pain that I haven't applied the January 1990 patches yet; I don't know if they'd fix the problem or not. -- Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can jay@splut.conmicro.com (eieio)| adequately be explained by stupidity. {attctc,bellcore}!texbell!splut!jay +---------------------------------------- Free the DC-10!
" Maynard) (02/11/90)
I went looking, and found (again) what the problem in making C news on
System V/AT was. The problem comes because, in large model only, the
nnfree() and nnafree() macros give the compiler indigestion. I had to do
the following, wherever it appeared (this example is from
libsmall/sys.slow.c):
/*
* Free current sys entry & associated memory. Zero currsys too.
*/
STATIC void
freecurrsys()
{
if (currsys != NULL) {
/* nnfree(&currsys->sy_name);
nnfree(&currsys->sy_excl);
nnfree(&currsys->sy_ngs);
nnfree(&currsys->sy_distr);
nnfree(&currsys->sy_cmd);
nnafree(&currsys);
*/
if (currsys->sy_name != 0) free(currsys->sy_name);
if (currsys->sy_excl != 0) free(currsys->sy_excl);
if (currsys->sy_ngs != 0) free(currsys->sy_ngs);
if (currsys->sy_distr != 0) free(currsys->sy_distr);
if (currsys->sy_cmd != 0) free(currsys->sy_cmd);
free(currsys);
currsys = 0;
}
}
Expanding the macro by hand resolves the problem. Analogous changes need
to be made wherever nnfree() and nnafree() are used.
--
Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can
jay@splut.conmicro.com (eieio)| adequately be explained by stupidity.
{attctc,bellcore}!texbell!splut!jay +----------------------------------------
Free the DC-10!davecb@yunexus.UUCP (David Collier-Brown) (02/12/90)
jay@splut.conmicro.com (Jay "you ignorant splut!" Maynard) writes: >Expanding the macro by hand resolves the problem. Analogous changes need >to be made wherever nnfree() and nnafree() are used. At the expense of suggsting the obvious, would it not be better to write a "foo_free" function and just have the macros expand to it? #define nnfree foo_free int foo_free(void *p) { return (p != 0)? free(p): (void *) NULL; } -- David Collier-Brown, | davecb@yunexus, ...!yunexus!davecb or 72 Abitibi Ave., | {toronto area...}lethe!dave Willowdale, Ontario, | Joyce C-B: CANADA. 416-223-8968 | He's so smart he's dumb.
henry@utzoo.uucp (Henry Spencer) (02/12/90)
In article <T+4:TZ@splut.conmicro.com> jay@splut.conmicro.com (Jay "you ignorant splut!" Maynard) writes: >Well, they run...but they fail in the middle. Expire complains about >running out of memory, sometimes saying that it's trying to read a line >of history, sometimes not; relaynews simply fails mysteriously. My >active file: >-rw-rw-r-- 1 usenet news 20865 Feb 10 15:50 /usr/lib/news/active >Not huge, but not trivial, either. Big enough to be a bad sign, I'm afraid. A 16-bit program only has 64KB of data space, and it wants to use some of that for other things. >Unfortunately, rebuilding just expire and relaynews in large model is >such a pain that I haven't applied the January 1990 patches yet; I don't >know if they'd fix the problem or not. Probably not. We haven't done anything lately that would cause a major drop in memory requirements. The prognosis isn't good, either. One of the things on my low-priority-to-do list for expire is a change that would save a lot of memory on small machines, at the expense of rather more CPU use, but there is no equivalent for relaynews that I know of. (Expire keeps an in-core copy of its control file, but uses it only when it runs across a hitherto-unknown newsgroup. Normal decisions are made based on a hash table with an entry per newsgroup. With a big active file, that hash table is big too. It could be eliminated, if one were sufficiently short of memory to accept doing a search of the control-file structure every time. Expire used to work that way, in fact; the hash table is just an optimization. Relaynews is a very different story, and cutting memory use there would probably be nasty and complicated. Barring some sudden inspiration about how to massively reduce memory use with a ten-line change -- not likely! -- that probably won't happen.) -- SVR4: every feature you ever | Henry Spencer at U of Toronto Zoology wanted, and plenty you didn't.| uunet!attcan!utzoo!henry henry@zoo.toronto.edu
zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (02/12/90)
>Big enough to be a bad sign, I'm afraid. A 16-bit program only has 64KB >of data space, and it wants to use some of that for other things. > >>Unfortunately, rebuilding just expire and relaynews in large model is >>such a pain that I haven't applied the January 1990 patches yet; I don't >>know if they'd fix the problem or not. Some 16 bit systems like the '286 in large model allow you to have as many 64kb data spaces as you want. No single object can exceed 64k bytes though. Anything that mallocs memory in small chunks should work. Things that need large linear arrays don't work. Compiling all of C news in large model should work. C news is quite good about not assuming an int = 32 bits. -- Jon Zeeff zeeff@b-tech.ann-arbor.mi.us or b-tech!zeeff
henry@utzoo.uucp (Henry Spencer) (02/13/90)
In article <+#4:94@splut.conmicro.com> jay@splut.conmicro.com (Jay "you ignorant splut!" Maynard) writes: >I went looking, and found (again) what the problem in making C news on >System V/AT was. The problem comes because, in large model only, the >nnfree() and nnafree() macros give the compiler indigestion... >Expanding the macro by hand resolves the problem... You might want to look at the new notebook/problems document, which mentions a compiler problem with nnfree() and friends on the HP Spectrum machines and gives an alternate version of the macro that seems to clear it up. We'd be curious to know if the same fix works on V/AT. More generally, we welcome reports of specific portability problems, and fixes to them, for inclusion in notebook/problems. We won't promise to fix them, especially when broken compilers are involved, but at least we can warn people about them. -- SVR4: every feature you ever | Henry Spencer at U of Toronto Zoology wanted, and plenty you didn't.| uunet!attcan!utzoo!henry henry@zoo.toronto.edu
henry@utzoo.uucp (Henry Spencer) (02/13/90)
In article <3+1:A3-@splut.conmicro.com> jay@splut.conmicro.com (Jay "you ignorant splut!" Maynard) writes: >>Has anyone ported C-news to Microport V/AT? ... > >It's not simple. In particular, expire and relaynews need to be compiled >in large model, or else they run out of memory... Question: are you answering "small" when build asks you whether it should use the small-address-space or large-address-space library? If not, you should be. -- SVR4: every feature you ever | Henry Spencer at U of Toronto Zoology wanted, and plenty you didn't.| uunet!attcan!utzoo!henry henry@zoo.toronto.edu
henry@utzoo.uucp (Henry Spencer) (02/13/90)
In article <WPM#J3=@b-tech.uucp> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: >Compiling all of C news in large model should work. C news is quite good >about not assuming an int = 32 bits. The fact that utzoo was a 16-bit machine until summer 1988 had a lot to do with this! :-) -- SVR4: every feature you ever | Henry Spencer at U of Toronto Zoology wanted, and plenty you didn't.| uunet!attcan!utzoo!henry henry@zoo.toronto.edu
randy@rls.UUCP (Randall L. Smith) (02/13/90)
In article <WPM#J3=@b-tech.uucp>, zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: >> Big enough to be a bad sign, I'm afraid. A 16-bit program only has 64KB >> of data space, and it wants to use some of that for other things. >> >>> Unfortunately, rebuilding just expire and relaynews in large model is >>> such a pain that I haven't applied the January 1990 patches yet; I don't >>> know if they'd fix the problem or not. > > Some 16 bit systems like the '286 in large model allow you to have as > many 64kb data spaces as you want. No single object can exceed 64k > bytes though. Anything that mallocs memory in small chunks should > work. Things that need large linear arrays don't work. I'm only familiar with the Microport 286 compiler and not sure about the other 16 bit systems. The (-Ml) large memory option will support only four 64K segments. TFM suggests a (-Mh) Huge memory option would theoretically support many (unlimited) 64K segments. Microport never supported the Huge memory option. It is true, no single object can exceed the 64K segment boundaries. Further, no single object can span any two 64K segments. I'm out on a limb here but, I think there can be but one 64K Instruction segment and upto three Data segments. So much for segmented architecture. :( A special compiler incantation must be used to prevent boundary expansion from happening. Long ago and far away I built straight, unpatched B-news on 2.2.2L. The 16-bit compress seemed to cause the bulk of the trouble. Finally with -Ml2et in the makefile (CFLAGS) = option, it built and ran successfully with no special patches. The -Ml2et switch prevents an object from spanning two segments and other good things. Unfortunately, I forget their meaning now. It is not too clearly documented in the Microport programming manual. I'm hoping this helps someone. Cheers! - randy Usenet: randy@rls.uucp Bangpath: ...<backbone>!osu-cis!rls!randy Internet: rls!randy@tut.cis.ohio-state.edu
" Maynard) (02/13/90)
In article <WPM#J3=@b-tech.uucp> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: >Compiling all of C news in large model should work. C news is quite good >about not assuming an int = 32 bits. I've been trying to avoid that, because of the nnfree() and nnafree() macro problems, and because small model runs faster (about 20-25%); I may have to bite the bullet, though. -- Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can jay@splut.conmicro.com (eieio)| adequately be explained by stupidity. {attctc,bellcore}!texbell!splut!jay +---------------------------------------- Free the DC-10!
zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (02/14/90)
>I'm only familiar with the Microport 286 compiler and not sure about the >other 16 bit systems. The (-Ml) large memory option will support only >four 64K segments. TFM suggests a (-Mh) Huge memory option would I used to run a 16 bit compress on Microport '286. It used more than 256k of memory (four 64k segments). -- Jon Zeeff zeeff@b-tech.ann-arbor.mi.us or b-tech!zeeff
" Maynard) (02/15/90)
In article <1990Feb12.193629.16193@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >In article <3+1:A3-@splut.conmicro.com> jay@splut.conmicro.com (Jay "you ignorant splut!" Maynard) writes: >>It's not simple. In particular, expire and relaynews need to be compiled >>in large model, or else they run out of memory... >Question: are you answering "small" when build asks you whether it >should use the small-address-space or large-address-space library? >If not, you should be. Yes, I am. What's the difference between the two? -- Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can jay@splut.conmicro.com (eieio)| adequately be explained by stupidity. {attctc,bellcore}!texbell!splut!jay +---------------------------------------- Free the DC-10!
" Maynard) (02/16/90)
In article <1990Feb12.193443.16079@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >You might want to look at the new notebook/problems document, which >mentions a compiler problem with nnfree() and friends on the HP Spectrum >machines and gives an alternate version of the macro that seems to clear >it up. We'd be curious to know if the same fix works on V/AT. I've applied the fix; unfortunately, I can't try it yet, since my copy of the 900117 patch has disappeared. As soon as I finih patching, I'll let you know how it does. BTW, you might take the note about System V/AT 2.3 out of there; the problem in offsetof() appears in 2.4 as well, and is probably generic to the Microport 286 products. The fast stdio stuff fails the test on my system as well. -- Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can jay@splut.conmicro.com (eieio)| adequately be explained by stupidity. {attctc,bellcore}!texbell!splut!jay +---------------------------------------- Free the DC-10!
randy@rls.UUCP (Randall L. Smith) (02/16/90)
In article <&*P#+1$@b-tech.uucp>, zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: >> I'm only familiar with the Microport 286 compiler and not sure about the >> other 16 bit systems. The (-Ml) large memory option will support only >> four 64K segments. TFM suggests a (-Mh) Huge memory option would > > I used to run a 16 bit compress on Microport '286. It used more than 256k > of memory (four 64k segments). Jon's observation led me back to the manual to see how this could be so. My faded, jaded memory dropped a bit somewhere. My fault. The segment of the Microport Software Development Manual I so adeptly corrupted reads; "Each segment register contains the logical base address of a memory segment. This logical address is translated into the physical base address of that segment in memory. Depending on how the segment registers are used, a program can address approximately 8192 (8k) segments of memory, FOUR SEGMENTS AT A TIME." Emphasis added is mine. So, the Large Memory model can support any number of 64K segments with the restriction, no single data array may exceed the 64K segment limits and whatever limits imposed by memory. BTW, the Huge memory model was to allow arrays larger than 64K. Thanks Jon. Cheers! - randy Usenet: randy@rls.uucp Bangpath: ...<backbone>!osu-cis!rls!randy Internet: rls!randy@tut.cis.ohio-state.edu
" Maynard) (02/16/90)
In article <7470@yunexus.UUCP> davecb@yunexus.UUCP (David Collier-Brown) writes: >jay@splut.conmicro.com (Jay "you ignorant splut!" Maynard) writes: >>Expanding the macro by hand resolves the problem. Analogous changes need >>to be made wherever nnfree() and nnafree() are used. > At the expense of suggsting the obvious, would it not be better >to write a "foo_free" function and just have the macros expand to it? >#define nnfree foo_free >int foo_free(void *p) { > return (p != 0)? free(p): (void *) NULL; >} This looks feasible, as well...I'll try it if the HP Spectrum fix doesn't work. -- Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can jay@splut.conmicro.com (eieio)| adequately be explained by stupidity. {attctc,bellcore}!texbell!splut!jay +---------------------------------------- Free the DC-10!
henry@utzoo.uucp (Henry Spencer) (02/17/90)
In article <PG8:&K:@splut.conmicro.com> jay@splut.conmicro.com (Jay "you ignorant splut!" Maynard) writes: >>Question: are you answering "small" when build asks you whether it >>should use the small-address-space or large-address-space library? > >Yes, I am. >What's the difference between the two? Libsmall uses different strategies for a couple of things than libbig; in particular, libsmall does not try to keep the entire active file in memory. -- "The N in NFS stands for Not, | Henry Spencer at U of Toronto Zoology or Need, or perhaps Nightmare"| uunet!attcan!utzoo!henry henry@zoo.toronto.edu
henry@utzoo.uucp (Henry Spencer) (02/17/90)
In article <QJ8:#9:@splut.conmicro.com> jay@splut.conmicro.com (Jay "you ignorant splut!" Maynard) writes: >BTW, you might take the note about System V/AT 2.3 out of there; the >problem in offsetof() appears in 2.4 as well, and is probably generic to >the Microport 286 products. Okay, done. Thanks. >The fast stdio stuff fails the test on my system as well. There are a depressing number of Unixes and pseudo-Unixes that have messed with stdio enough to make our fast-stdio stuff unusable. One would hope that they'd also sped up stdio in the process, but this generally seems to be wishful thinking. -- "The N in NFS stands for Not, | Henry Spencer at U of Toronto Zoology or Need, or perhaps Nightmare"| uunet!attcan!utzoo!henry henry@zoo.toronto.edu
henry@utzoo.uucp (Henry Spencer) (02/18/90)
In article <Z.9:YY&@splut.conmicro.com> jay@splut.conmicro.com (Jay "you ignorant splut!" Maynard) writes: >>>Expanding the macro by hand resolves the problem... >> >> At the expense of suggsting the obvious, would it not be better >>to write a "foo_free" function and just have the macros expand to it? > >This looks feasible, as well...I'll try it if the HP Spectrum fix doesn't >work. And I'll add a suggestion along those lines to notebook/problems (which now mentions the Microport problem and says that the Spectrum fix might work). -- "The N in NFS stands for Not, | Henry Spencer at U of Toronto Zoology or Need, or perhaps Nightmare"| uunet!attcan!utzoo!henry henry@zoo.toronto.edu