A bug? In Adobe Software?
Say it's not so!
1188 publicly visible posts • joined 23 Sep 2013
The quoting of speeds achieved just once, under ideal conditions needs to be replaced with a legally binding real world performance figure. If a device cannot consistently average the advertised speed it is then deemed faulty and the vendor is required to refund or replace. What's to stop me from claiming I have a chip that is "up to" twice as fast and only costs "from" one penny?
The only people who would find it more convenient to use this rather than an Oyster card are those that go around with phone permanently in hand. Generally, those irritating types that spend the entire journey shouting "I'm on the bus" and other inanities down it, or those that tap away at some game ensuring a constant stream of tinny beeps to fray the nerves of nearby passengers.
Anyone who would find using a phone more convenient (and this would work for iPhone users too) could always glue an oyster card to the back of it.
Why not just publish monthly charts of national and regional coverage and let market competition sort the problem out? Customers who spend virtually all their time in, say, the south-west don't really care about coverage elsewhere and will be looking at the number one or two for their area. Those who travel further afield may want the national chart topper. It will encourage the big firms to get a good place in the national chart by filling the holes in their coverage while leaving the smaller ones a chance to shine by specialising in a region or two.
Quite right about the A and X registers. There were indeed also B registers of which B0 was actually a set of connections soldered to chassis earth! B0 gave a handy constant of zero and could not be changed. By convention B1 had the value 1, but this was not fixed by the hardware. Woe betide the programmer who forgot to kick off with a SB1 1 instruction.
There was a stack, but not in the conventional sense. It was an instruction stack and if you could code your loops so that they fitted in the stack, they ran a lot faster as no instruction fetches from memory were necessary. The MNF Fortran compiler mentioned earlier did a fair job, but it was the FTN compiler at its higher optimisation levels that did the best job of getting those inner loops slimmed down and in the stack. Took a while longer to compile, but those extra seconds could shave hours off a complex scientific task.
The other interesting part of the architecture was the peripheral processors. The CPU was completely incapable of any I/O, so this was down to the PPs. They had parallel access to the central memory, so a program requiring I/O would write a request to a certain memory location which was monitored by the PPs and they would then perform the required I/O to a central memory buffer pointed to by the request. The program could carry on running while waiting for the request, or could relinquish control to another task and be recalled after completion.
15 or 30 bit instructions packed into these words, or 10 characters of 6 bits apiece. The peripheral processors used 12-bit words and had all of 4k of these to perform their tasks. Octal was the order of the day, hexadecimal has no place in a 6-12-15-30-60 bit world. And not forgetting 18-bit addresses of course.
I can only really comment on the Control Data aspect of the job requirements but I think I can safely say that anyone who had knowledge of both central and peripheral processor assembly languages and architectures some 40-odd years ago will definitely not be looking for a museum job. There may be a handful prepared to do some part-time work, but if they are up to the CDC requirements, they will be seriously lacking in IBM/DEC/etc. To a CDC systems man (or even the extremely rare woman), the architectures and languages on these other systems are arcane and illogical and to be kept at bargepole distance. I'm sure the converse is also true.
What the job needs (if the budget will stretch to it) is a keen but inexperienced person and half a dozen part-time consultants to steer him/her in the right direction.