Idiotic programming style edicts
in [General Programming]
|
Prev: System Calls
Next: Warning to newbies
From: Marco S Hyman on 19 Mar 2010 19:00 scott(a)slp53.sl.home (Scott Lurndal) writes: > Another example (real-world, from data comm module in a Burroughs MCP) > > .TEXT BST -HHT Must move text too > .BIGUN LIX IH-1AV X5 IX1 Get first header > CPN NILPTR IX1 End of list? > EQL +NAKU Yes, NAK & Unlock > MVW TP-FWD X1 IH-1AV X5 Set new flink > BST TP-BIG X1 Note large header > .GOTIT UNLK IH-TLK X5 Unlock tag pool > MVW DP-HDR X6 TP-ENT X1 Move header to tag > SIX -TAGP IX1 Save tag pointer > > scott Line by line comments can be interesting. I think it was the Burroughs Medium Systems dumpall program that, if you read closely, would find a treatise on go carts. I don't remember if it was written by one author, or a back and forth between several :-) /\/\arc
From: Scott Lurndal on 19 Mar 2010 19:35 Marco S Hyman <marc(a)snafu.org> writes: >scott(a)slp53.sl.home (Scott Lurndal) writes: > >> Another example (real-world, from data comm module in a Burroughs MCP) >> >> .TEXT BST -HHT Must move text too >> .BIGUN LIX IH-1AV X5 IX1 Get first header >> CPN NILPTR IX1 End of list? >> EQL +NAKU Yes, NAK & Unlock >> MVW TP-FWD X1 IH-1AV X5 Set new flink >> BST TP-BIG X1 Note large header >> .GOTIT UNLK IH-TLK X5 Unlock tag pool >> MVW DP-HDR X6 TP-ENT X1 Move header to tag >> SIX -TAGP IX1 Save tag pointer >> >> scott > >Line by line comments can be interesting. I think it was the >Burroughs Medium Systems dumpall program that, if you read closely, >would find a treatise on go carts. I don't remember if it was >written by one author, or a back and forth between several :-) > >/\/\arc Actually, I wrote part of DMPALL. Specifically the code that added conditional criteria for record extraction. DMPALL was developed by several engineers over a 20 year time frame. (Although I didn't keep a listing of DMPALL, and don't recall the gocart stuff; not having seen the source since 1986). What may be the last Medium Systems in the USA was just shut down two weeks ago, after running since 1988. I have an emulator, however, and am working on getting a B974 emulation working so I can support CANDE. scott (first @ last dot org)
From: Joe Morris on 19 Mar 2010 21:11 BruceS wrote: > According to The C Standard, 6.4.9p2, C allows comments that *do* > automatically terminate at the end of the line, just as this style of > comment works in C++. One could avoid the bug in the earlier code by > writing it: > > x // The variable x > = // is assigned > x // its value > + // plus > 2 // pi > ; // . > > Oh, I'd better put in a :) or we'll have started another pointless > whinefest. Thread drift warning... My (non-parity-checked) memory tells me that there was a code block in the MFT-1 (OS/360 release 14 or maybe 13) nucleus that had register equates named the traditional Rn (0 <= n <= 15), but with Rn set equal to a value other than n. I *think* it was in the FLIH (First-Level Interrupt Handler), in code assembled at sysgen. I always assumed (as speculation) that when the code was written there was one register use convention that was later changed, and someone was too lazy to chase all of the register references in the code and rename them. Does this sound familiar to anyone? Joe Morris
From: ArarghMail003NOSPAM on 19 Mar 2010 23:19 On Fri, 19 Mar 2010 21:11:04 -0400, "Joe Morris" <j.c.morris(a)verizon.net> wrote: <snip> > >Thread drift warning... > >My (non-parity-checked) memory tells me that there was a code block in the >MFT-1 (OS/360 release 14 or maybe 13) nucleus that had register equates >named the traditional Rn (0 <= n <= 15), >but with Rn set equal to a value other than n. I *think* it was in the FLIH >(First-Level Interrupt Handler), in code assembled at sysgen. I always >assumed (as speculation) that when the code was written there was one >register use convention that was later changed, and someone was too lazy to >chase all of the register references in the code and rename them. > >Does this sound familiar to anyone? > I don't know about the location you mentioned, but I think I have seen it in other parts of the source. Can't find any examples, though. If you should happen to remember the source file name, I could look. However, a lot of the routines I looked at appear as if somebody at some point in time said: "Thou shall not use hard coded numbers", because I see a lot of equates like "d1 equ 1". :-) -- ArarghMail003 at [drop the 'http://www.' from ->] http://www.arargh.com BCET Basic Compiler Page: http://www.arargh.com/basic/index.html To reply by email, remove the extra stuff from the reply address.
From: Andrew Swallow on 20 Mar 2010 00:27
ArarghMail003NOSPAM(a)NOT.AT.Arargh.com wrote: > On Fri, 19 Mar 2010 21:11:04 -0400, "Joe Morris" > <j.c.morris(a)verizon.net> wrote: > <snip> >> Thread drift warning... >> >> My (non-parity-checked) memory tells me that there was a code block in the >> MFT-1 (OS/360 release 14 or maybe 13) nucleus that had register equates >> named the traditional Rn (0 <= n <= 15), >> but with Rn set equal to a value other than n. I *think* it was in the FLIH >> (First-Level Interrupt Handler), in code assembled at sysgen. I always >> assumed (as speculation) that when the code was written there was one >> register use convention that was later changed, and someone was too lazy to >> chase all of the register references in the code and rename them. >> >> Does this sound familiar to anyone? >> > I don't know about the location you mentioned, but I think I have seen > it in other parts of the source. Can't find any examples, though. > If you should happen to remember the source file name, I could look. > > However, a lot of the routines I looked at appear as if somebody at > some point in time said: "Thou shall not use hard coded numbers", > because I see a lot of equates like "d1 equ 1". :-) > That is a common one. What happens is that d1 equ 1 but m1 changes m1 equ 2 This means that a third of the +1 become +2. Without the use of macros there is plenty of room to get that edit wrong. Andrew Swallow |