Code Puzzle

[Churchill]

Not so much a code puzzle then, more the trigger for WWIII.

You'd think so...

[Churchill]

Alexi, after you have finished doing Churchill's work for him how do you fancy doing some of mine?

I quite fancy going to the pub for a few at lunch time but I have a deadline.

If it helps I can wrap my tasks up as a 'puzzle' and say it is just a bit of fun.

[AtW]

If you follow the instructions you will find it obvious that the code hasn't hung.

That's much better written assembly, much obliged partner.

I am going to leave it running - hopefully it's less than an hour or something.

[AtW]

Hmm, just run it now with Unix date command before to time it and I can see numbers incrementing on top of the screen - so you do access video memory, this surely can't be fast - I assume it's optional unnecessary feature that is only needed if code is so slow that the user needs to know when it ends?

[AtW]

Ok, this video clock is either slowing all down (will find out tonight) or the max number is too high.

Consequently for testing purposes I am going to limit counting up to lower number as otherwise it is impossible to benchmark the damn thing.

[Churchill]

Hmm, just run it now with Unix date command before to time it and I can see numbers incrementing on top of the screen - so you do access video memory, this surely can't be fast - I assume it's optional unnecessary feature that is only needed if code is so slow that the user needs to know when it ends?

It's meant to display the f**king counter you moron!

Jesus christ man!!! Just read the flaming thing and either optimise it and partake in the "fun" or just f**king leave it alone!

[AtW]

It's meant to display the f**king counter you moron!

Did it not occur to you that in this case displaying of progress counter may be the main reason for slow execution?

Also, as a side note - you need to moderate your temper and act more like a professional: this way your unprofessional behavior compounds your poor assembly optimisation skills.

[Churchill]

Did it not occur to you that in this case displaying of progress counter may be the main reason for slow execution?

Also, as a side note - you need to moderate your temper and act more like a professional: this way your unprofessional behavior compounds your poor assembly optimisation skills.

My code isn't meant to be optimised, I posted it on here so that real engineers, not those that ponce about complaining about the use of the wrong tools like a fairy, but real engineers who know what they're talking about - and let's be clear about this, the evidence points to you being a poncing hand-wringing fairy - can have a play with it and if they so choose optimise it, tinker with it or whatever.

Now AtW, this is my final response to you on this subject, **** off, Seriously!

[AtW]

I've programmed assembly language in the past.

This made me very patient person because I frequently had to reboot computer as it hung due to bad code - those were the days

You are acting very unprofessionally just now - tonight I am going to optimise that code and show to you how it should have been written (if you wanted high performance), though it seems to me the main flaw in it is actual displaying of counter - common rookie error when displaying progress indicator is the actual slow down of the code: that's my preliminary judgement, I'll see if it is correct tonight.

[NickFitz]

You are acting very unprofessionally just now - tonight I am going to optimise that code and show to you how it should have been written (if you wanted high performance), though it seems to me the main flaw in it is actual displaying of counter - common rookie error when displaying progress indicator is the actual slow down of the code: that's my preliminary judgement, I'll see if it is correct tonight.

The purpose of the program is to display the counter:

It was a 60 byte piece of code that displayed and incremented a counter from 0000000000000000 to 9999999999999999

It doesn't make any sense to say that fulfilling the specified purpose of the program is a "flaw".

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.