Code Puzzle

[AtW]

As for the stuff about writing to display RAM being an IO bottleneck: yes, but if you're going to display something then you're going to write to display RAM either directly as in this code, or indirectly via a BIOS or OS call that also writes directly to video memory.

Nice try Nick but no cigar

How does one optimise bottleneck of displaying counter in slow video RAM? Simples - you don't have to do it for every count of which there will be many millions - human eye simply won't catch the difference and normal video monitors won't show more than 200 changes per second anyway!

Consequently even if you want to keep this counter shown then the most obvious optimisation is to show it every X times, human eye won't see the difference.

As far as I am concerned the real optimisation was in the loop itself which has got blatantly poor assembly, I've even given example at start of the post.

 

[NickFitz]

It was a 60 byte piece of code that displayed and incremented a counter from 0000000000000000 to 9999999999999999 I invited people to optimise it as a bit of fun.

Fencepost problem: you're displaying seventeen digits, not sixteen.

Your software does not work - it does not display like you claimed above countdown, my compiled size is 60 bytes on 32 bit system.

WFM, XP SP2, command prompt. (Well, works apart from the above fencepost problem - the code runs perfectly well but doesn't meet the spec.)

 

[AtW]

WFM, XP SP2, command prompt. (Well, works apart from the above fencepost problem - the code runs perfectly well but doesn't meet the spec.)

It runs too slowly - I would not call that perfect...

Tonight I'll rewrite it - it will be smaller, and much faster - also display this stupid counter

 

[Churchill]

Fencepost problem: you're displaying seventeen digits, not sixteen.



WFM, XP SP2, command prompt. (Well, works apart from the above fencepost problem - the code runs perfectly well but doesn't meet the spec.)

Thanks Nick, modified as follows...

A 100
mov ax,2
int 10
mov ax,b800
mov ds,ax
mov ax,30
xor di,di
mov cx,f
ds:
mov [di],al
inc di
dec cx
inc di
cmp cx,0
jne 113
mov di,1E
mov cx,10
mov al,[di]
inc al
cmp al,3a
je 12F
mov [di],al
jmp 11D
mov al,30
mov [di],al
dec di
dec di
cmp di,0
je 13C
jmp 123
mov ax,4c00
int 21

N test.COM
RCX
41
W
Q

 

[AtW]

I'll get it working faster and have code size of under 50 bytes.

If I fail to achieve these easy to achieve goals then I won't ever post here again

 

[Churchill]

I'll get it working faster and have code size of under 50 bytes.

If I fail to achieve these easy to achieve goals then I won't ever post here again

Quoted

 

[NickFitz]

Some rather obvious minor improvements:

mov ax,b800
mov ds,ax
mov ax,30
xor di,di
mov cx,0f
ds:
mov [di],al
add di, 2
dec cx
jne 10e
mov di,1e
mov cx,0f
mov al,[di]
inc al
cmp al,3a
je 128
mov [di],al
jmp 116
mov al,30
mov [di],al
sub di,2
je 133
jmp 11C
mov ax,4c00
int 21

The following is based on 8086 timings:

Using sub di,2 instead of the two dec dis (and the corresponding add v. inc) will save 2 cycles (3 + 3 as opposed to 4) although it doesn't help on space: we lose a byte (2 as opposed to 3). However, the two places where we have cmp <register>, 0 both come after instructions that set the Z flag, so the test is redundant and we can just branch on the condition anyway: this saves 4 cycles for each compare, and 3 bytes.

By my reckoning that saves (2 * 16) + (4 * 16) + (2 * 10000000000000000) + (4 * 10000000000000000) = 60000000000000096 cycles in total. That should save around 7,500,000,000 seconds on an 8MHz processor, reducing the total running time by 237 years

Oh, total size: 56 bytes

And now I really must be getting on with something useful

 

[AtW]

Nick stop posting spoilers!!!

I'll beat you Nick also -

 

[Churchill]

Some rather obvious minor improvements:

mov ax,b800
mov ds,ax
mov ax,30
xor di,di
mov cx,0f
ds:
mov [di],al
add di, 2
dec cx
jne 10e
mov di,1e
mov cx,0f
mov al,[di]
inc al
cmp al,3a
je 128
mov [di],al
jmp 116
mov al,30
mov [di],al
sub di,2
je 133
jmp 11C
mov ax,4c00
int 21

The following is based on 8086 timings:

Using sub di,2 instead of the two dec dis (and the corresponding add v. inc) will save 2 cycles (3 + 3 as opposed to 4) although it doesn't help on space: we lose a byte (2 as opposed to 3). However, the two places where we have cmp <register>, 0 both come after instructions that set the Z flag, so the test is redundant and we can just branch on the condition anyway: this saves 4 cycles for each compare, and 3 bytes.

By my reckoning that saves (2 * 16) + (4 * 16) + (2 * 10000000000000000) + (4 * 10000000000000000) = 60000000000000096 cycles in total. That should save around 7,500,000,000 seconds on an 8MHz processor, reducing the total running time by 237 years

Oh, total size: 56 bytes

And now I really must be getting on with something useful

Good lad! However, it don't work... You've broked it. You've not got the 5 bytes on the front that set the display mode.

 

[AtW]

STop posting spoilers - all entries should be PMed to the dog who can announce byte sizes etc