Mixed Signals
Any sufficiently advanced information is indistinguishable from noise
Friday 8 June 2007, 3:48 PM
FOR F=1 TO 100:PRINT "JOURNOZ ROOL!";:NEXT F
Sure, if you're covering a very technical beat then it helps if you know what people are talking about. But most of the issues -- even in the wild world of computers, networks and the like -- have little to do with the mechanics of coding. Rather, they come from the very human side of the business, the motivations behind actions and the differences between what people say and what they do. Add in conflict for resources, the difference between vision and its implementation, the mismatch between ability and imagination, the iron curtain between public and corporate truth, and you're getting somewhere. Really, it doesn't much matter whether you're able to write a nicely turned applet or not (although it may be useful if you spent some time as a programmer in the belly of the beast, watching what happens).
I had a long and very dispiriting argument on this very point with a developer of my acquaintance, round about the time I stopped coding and started writing. He was bitterly disappointed in me, and said that unless I was actually capable of doing everything I was writing about, I was not qualified. "You're just deskilling," he said. I pointed out, I think reasonably, that since there was an awful lot to write about - chip design, wireless systems, networking, servers, security - it wasn't actually possible to follow his prescription, and that there were good things about being a generalist who could join the dots rather than just colour them in. He didn't agree, but I never quite understood why.
I've still got my chops, though. The piece in journalism.co.uk ends up with a geeky joke that:
foreach (@commentator) { while $opinion = 1 { $debate = "ongoing"; } }
to which I say..
BLSHT EQU 01H ; value expected from argument
CMNT EQU 1000H ; start of comment buffer
TOLDUSO DEFB "It's all rubbish!",0
ENT:
LD HL,CMNT
CHK4BS:
LD A,(HL)
INC HL
CP BLSHT
JP NZ,CHK4BS
LD DE, TOLDUSO
CALL WRITE_DE_TO_CONSOLE
RET
PreviousComments on this post
Shouldn't you have used CPIR instead?
I'm not saying it's efficient... but then, CPIR wasn't _that_ efficient anyway. I seem to remember never actually finding a use for it; once you lost the flexibility of choosing your registers, doing all that clever-clever stuff with non-setting flags in loops and so on, you never got a T-state advantage.
But then, EVERYONE knew that RISC was better than CISC...
I've been hacking with the z80 code and I've come up with the
following three versions which prove that for your particular code CPIR would be a couple of T states faster, but I take your point.
BLSHT EQU 01H ; value expected from argument
CMNT EQU 1000H ; start of comment buffer
TOLDUSO DEFB "It's all rubbish!",0
ENT1:
LD HL,CMNT
CHK4BS:
LD A,(HL) ;7
INC HL ;6
CP BLSHT ;7
JP NZ,CHK4BS ;10 = 30 TStates
LD DE, TOLDUSO
CALL WRITE_DE_TO_CONSOLE
RET
ENT2:
LD HL,CMNT-1
LD A,CHK4BS
CHK4BS:
INC HL ;6
CP (HL) ;7
JP NZ,CHK4BS ;10 = 23 TStates
LD DE,TOLDUSO
CALL WRITE_DE_TO_CONSOLE
RET
ENT3:
LD HL,CMNT
LD A,CHK4BS
LD BC,0
CHK4BS:
CPIR ;21 TStates for each non-match
JR NZ,CHK4BS
LD DE,TOLDUSO
CALL WRITE_DE_TO_CONSOLE
RET
I do feel slightly worried that I had enough time on my hands to bother to go and find this out and I would have kept quiet except you threatened to expose me anyway
