Not at the moment, I'll try and remember to have a look at that next time I test a module. Currently everything is shuffled into the corners so I can start the construction of the decoder frame.
How would one find this out? Sounds like it would be fun to figure out how to develop all possible reasonably compact instruction combinations to achieve the same basic block and then compare timings.
I guess I need to sit down and study this stuff in more detail, but do I understand correctly that the code you shared makes the decisions for each position independently? I am just astonished that this produces any coherent output. Also it is not clear to me how the length of the output sequence is determined.
I wrote some code that does something like that. Learned very quickly that it's essentially impossible without a lot of manual data capturing - specifically is this a pack of 6 or 10 etc.
Still for the bits where it worked I was surprised how big the variances per unit were
How did the plugboard work? Is it literally 31 steps across (or down, or whichever way it was oriented) and you connected the bits in each step to locations that selected an operation?
Or was it more like microcode where you had to consider some contextual implementation details as well?
Still not an option on the platform in the article, though. You'd have to make your own pop count and implement it likely with a loop and bit shifting. It's almost certainly going to take more instructions than this and end up with as many branches as a result. The instruction set is very limited. Though quoting myself:
>> On an instruction set with that [pop count], I imagine it would be a useful trick though.
That sounds extremely interesting. I had not noticed that feature before. Do you happen to have some example input at hand that triggers such an adjustment?
Look at ASCII mapped out with four bits across and four bits down and the logic may suddenly snap into place. Also remember that it was implemented by mechanical printing terminals.
reply