goldfarb (04/14/83)
Following is a section of code from doprint.s in 4.1bsd. Could someone explain the 'comet' comment? ----- __doprnt: .word 0xfc0 # uses r11-r6 movab -256(sp),sp # work space movl 4(ap),r11 # addr of format string movl 12(ap),fdesc # output FILE ptr movl 8(ap),ap # addr of first arg clrl nchar # number of chars transferred loop: movzwl $65535,r0 # pseudo length movl r11,r1 # fmt addr # comet sucks. movq *fdesc,r4 subl3 r1,r5,r2 jlss lp1 . . .
msc (04/14/83)
If my memory serves correctly Comet is the code name given to the vax 11/750 during its development at DEC. The comment "Comet sucks" presumably refers to the fact that a certain block move instruction, which was used in _doprint.s and hence in almost every program in 4.1bsd, worked differently on the 750 than the 780. It would cause segmentation faults when the areas of memory involved overlapped (I think). This difference necessitated the re-compilation of almost everything in the 4.1bsd release. It turns out the the 750 executes the instruction exactly as specified in the VAX architecture manual and it is the 780 that is at fault. Mycroft Holmes
aps (04/15/83)
Mycroft Holmes or qubiz!msc (which ever) is correct in that the name comet was given to the 11/750 project (star->780, and nebula->730). The problem was that the doprint was using the movtuc (Move translated until character) to move UNIX null terminated strings instead of the "normal" VAX and/or VMS counted strings. The string lengths were set to the maximum for both source and destination, and the "escape" character was set to the null character. The table was just an identity table, translating a charater into itself. The architecture manual (even the first manuals) stated that if the source string and destination string overlapped (and their starting addresses were not equal which allowed translation in place), the result would be unpredictable. The VAX-11/780 actually did not really care. The MOVTUC was implemented in a straight forward manner. The 750 however, performed some "optimizations" which required adherence to the limitation stated in the books. So, it didn't work on the 750. Hence Joy's (or Shannon's) comment about the wonderful comet. The comet went on to be one of the favorite machines of the DEC UNIX Engineering Group ... Armando.
pbr (04/19/83)
The comment "comet sucks" in the version of doprnt.s that Ben Goldfarb found probably refers to the necessity of doing the extra move or address formating on the VAX-750. "Comet" was the code name for the 750 during development.