blarson@blars (10/11/90)
I finally upgraded my qt20x to osk 2.3. If I'd known it would cure so
many of my outstanding problems, I wouldn't have hesitated so long.
The few new bugs are so minor in comparison.... (Note: the
motherboard still has residual crud that won't come off due to a broken
pipe in the apartment above. I had attributed most of my supposed
hardware problem to this.)
Fixed:
nasty C compiler bugs dealing with "string"[0] and sizeof("string").
My system actually keeps the correct time rather than loosing several
hours a day. I though this was a hardware problem.
My Newburry data disk drive now works. I'd heard that SCSI support
was better at 2.3, so this wasn't a total surprise. It's nice not
haveing to look for something else to delete every few days. (Usenet
promises to use as much disk space as I let it, however. 300 meg
isn't infinite.)
The tape drive Frank Hogg sold me to go with the system now works.
Since Frank claimed not to have problems with them, I was wondering if
this was a hardware problem too. Now I can even back up my disk drive.
Broken:
The "dir -e" format has inexplicably changed by one column. This
broke mg, which parses the output from "dir -e".
"." is apperently no longer included in the default include file
search rules in the C compiler. Adding "-v=." to a make file fixed
this. (This only applies to compiling files out of subdirectories.)
There doesn't seem to be a way to write an ANSI-like OFFSETOF macro
under the new C compiler. The new C compiler seems to think:
(((char *)(&((struct foo *)0)->bar)) - ((char *)(struct foo*)0))
is a pointer-valued expression. (Don't ask me what it thinks it
points to.) The other semi-portable offsetof definition produces the
correct type, but very wrong values.
The age coumn of procs now accumulates. This is wrong and useless.
I can't boot off my Newburry. I get endless "error 215" messages.
Still broken:
My batery-backup clock still doesn't battery backup. Replacing the
batter did not cure the problem.
Occasional disk hangs requiring reboot. Usually occur durring the r68
phase of a make. There is some improvement: it now gives error 68:254
and returns to the shell. Further access of /h0 doesn't work.
Flopies can be accessed. Has anybody else experienced this problem?
(Since the hard drive and cable have been replaced, those arn't the
problem.)
Usenet:
This is the second article I've let escape from my qt20x running cnews
and rn. Mail and uucp are the main requirements besides testing and
documentation before I release it on the world. The C compiler bug
fixes let me back out some nasty changes I had had to make to cnews.
So fourth:
Microware should worry about fixing the bugs and making their compiler
ANSI compatable before seriously considering changes like register use
on argument passing. The compiler produces such poor code that a few
extra instructions here or there won't make any real difference.
Passing arguments in registers will be a real win if the compiler ever
does optimize. The vast majority of the programs I wait for are disk
bound, implementing a caching rbf would make orders of magnatude more
difference.
[apologies for the double signature, it's due to the backdoor way I
currently transfer news to and from my qt20x.]
--
blarson@usc.edu
C news and rn for os9/68k!
--
Bob Larson (blars) blarson@usc.edu usc!blarson
Hiding differences does not make them go away. Accepting
differences makes them unimportant.jejones@mcrware.UUCP (James Jones) (10/11/90)
In article <112@blars> blarson@blars writes: >"." is apperently no longer included in the default include file >search rules in the C compiler. Adding "-v=." to a make file fixed >this. (This only applies to compiling files out of subdirectories.) K&R 1st edition says the following about #include semantics, in canonically vague fashion: "A compiler control line of the form #include "filename" causes the replacement of that line by the entire contents of the file filename. The named file is searched for first in the directory of the original source file, and then in a sequence of standard places." The 2**6 dollar question is, is "the original source file" the file whose name was initially handed to the compiler, or the file containing the #include directive? The preprocessor formerly thought it was the former, and indeed X3J11 seems to think, if one reads the Rationale, that the former was intended--but the commonly-used Unix C preprocessor behaves as if the latter were intended. There were sufficient complaints, not to mention that the latter interpretation makes somewhat more sense by making nested #includes with relative pathnames not depend on the path of the file being compiled, that cpp's interpretation was changed to the latter, as, I recall, mentioned in release notes. (That's not the only debatable behavior of cpp. K&R 1st edition's "Text inside a string or a character constant is not subject to replacement" in 12.1 versus cpp's, and Reiser's, behavior on #define ctrl(a) ('a' - ' ') char ctrlx = ctrl(x); is another example.) >Microware should worry about fixing the bugs and making their compiler >ANSI compatable before seriously considering changes like register use >on argument passing. To the best of my knowledge, Microware's 680xx C compiler parameter passing, aside from the relatively recent changes to let one pass structures and unions, has been unchanged for a long time. The most recent changes to improve code generation have involved taking advantage of the "as if" rule by avoiding superfluous widening of operands. James Jones
blarson@blars (10/15/90)
In article <3343@mcrware.UUCP> jejones@mcrware.UUCP (James Jones) writes: >In article <112@blars> blarson@blars writes: >>"." is apperently no longer included in the default include file >>search rules in the C compiler. [discussion of #include omited] >cpp's interpretation was changed I agree that the changed version is supirior, however I don't see why it can't search both directories. >mentioned in release notes. Not as far as I can find. Page number please. -- blarson@usc.edu C news and rn for os9/68k! -- Bob Larson (blars) blarson@usc.edu usc!blarson Hiding differences does not make them go away. Accepting differences makes them unimportant.