Software Engineering : My History of Odd vs Even

I've been a avid fan of Intel's processors since my very first PC, powered by an Intel 80486 SX-25 it taught me so much, it also got me into a lot of trouble once, being an SX it was essentially a DX unit with a failed floating point unit at fabrication.  But Intel being the trixsy tech wizards they are, they didn't throw all those chips away, they simply disabled the broken portions, kept the working addition and subtraction sides and sold them under the SX label.

This of course led to some interesting differences between the SX & DX chips, the most obvious being the multiplication behaviour, on a DX to multiply to numbers you simply loaded each into a register and executed the one step multiply.  However, on an SX you loaded the start value, and the denominator into two registers and then looped through for a number of times adding them.  So the pseudo assembly code for it might look like this:

      LDA 3

      LDB 10

MUL:  ADD LDA,LDA

      DEC LDB

      JNZ LDB,MUL

      SAV LDA,RESULT

Where we find us loading up the two registers, then performing an add in a loop until we've added enough times.  This is of course a lot slower than:

      LDA 3

      LDB 10

      MLT LDA,LDB

And, the more you multiply the slower the SX could behave.  It wasn't as simple as this, however, for demonstration purposes we'll assume it was, there's no need to comment telling me I'm a moron (again) I know I am, but this is only a demo.

      

But this little SX machine was the only machine I had, and I was moving my programming skills from the playground of the Atari ST to the PC proper, and so I chose to try and get a lot of juice out of the machine.  On trick I learned was to page through screen memory scanning for shapes, but of course I quickly needed a bunch of math functions.  Using the CMath library was quite slow on the SX, so I started to find quicker home-brew alternatives.

Initially I had no idea I was working around my own CPU's hindrances (I only found this out later, when I realised on a DX2-66 chip I was getting magnitudes better performance).

One hunderance, of function, I worked around was odd & even... To calculate this, you would usually use a remainder, by division, in C this might look like this:

int remainder = 34 % 2;

Remainder would have a zero value for even values

const bool OddEven (const int& p_Value)

{

    return ( ( p_Value % 2 ) == 0 );

}

I was doing this in Pascal at the time, the syntax of which I have forgotten.  But you can see, it is a fairly simple function call, quite non-descript.  My problem on the SX was it ran so slowly.  A lot faster was to convert the value into a string, and inspect the last character!

bool l_IsEven = true;

int l_Number = 42;

char* l_str = new byte[16];

memset ( l_str, 0, 16 );

sprintf( l_str, "%i", l_Number );

int l_lastCharacter = strlen(l_str);

switch ( l_str[l_lastCharacter-1] )

{

     case 1:

     case 3:

     case 5:

     case 7:

     case 9:   l_IsEven = false;

                   break;

}

So, we get a value in l_IsEven more quickly, and it was indeed quicker for me to do this...

However, when I first looked at this problem, I had no itoa, nor sprintf, all I had was integer control.  Indeed, in the programming language suite I started with the only way to get text easily from a value reference to a string of characters was to write them to the screen with "write" and then to move back to the start of the line with a return carriage, and then to "read" the line again.

This was very very very slow, much slower than even the switch statement bastardization above.

So, I set about it the most logical way my 14 year old mind could think of...

It took the number, and did this:

bool l_IsEven = false;

int l_Number = 12354;

while ( l_Number > 10000 )

{

     l_Number = l_Number - 10000;

}

while ( l_Number > 1000 )

{

    l_Number = l_Number - 1000;

}

while ( l_Number > 100 )

{

    l_Number = l_Number - 100;

}

while ( l_Number > 10 )

{

    l_Number = l_Number - 10;

}

switch ( l_Number )

{

    case 0:

    case 2:

    case 4:

    case 6:

    case 8:   l_IsEven = true;

                 break;

}

This of course was totally horrible, and I quickly stopped using it in favour of the string method, and later in favour of the remainder function.

However, this horrible history of code remained in one of my header libraries, at the time they were Turbo Pascal Unit files (TPU), but when I went to University at 18, some four years after writing this original code I had tried to convert some of my Pascal support libraries to C and then C++.

One of the legacy calls I converted, without even looking, with an automatic tool was this very stupid function above... And yes, it ended up in at least one degree level project (oh what a fool I looked).

P.S. I'm sorry to report, I've never owned an AMD processor... However, I did have a Cytrix x86 to upgrade this very Intel Chip!