Since I started the ball rolling with the 'portable' angle, I'd better act as referee!

Erik - We all know that there is no way of getting portable c as efficient as as couple of assembler instructions embedded in the code. However, there can be more efficient ways of doing parity in portable c and there's been healthy discussion of this. Parity is not only used for serial comms as Dan suggests. Recently I did some encryption code that used parity that I converted from PIC asm to portable 'c'. It still ran clock for clock faster in 'c' on the ARM vs the PIC in asm! And it didn't use anything 32bit - it was all 8 bit operations.

It is always worth investigating techniques that are portable when writing code and then weighing up the performance cost. On the '8051 the performance cost may be massive - so that can be a reasonable justification to go to assembler. Sometimes, if the project is small enough, then you can ignore the portability angle as to recode for another architecture etc is not a large task. If the code took man-months to write, that is a significant investment in time (money). Most of my projects are only a few thousand lines of code and I do not try to make the i/o portable - that is really just a waste of time unless you code is to run on many architectures from the outset. I do, however, try to localise the i/o specific code. Of course Erik, I know you realise this, but Dan had a cogent argument.

Thanks Dan for your contribution of other portable 'c' solutions. If I was writing for a 12 clocker 8051, then I'd most likely choose the assembler option, if it was an ARM at 60MHz, then I'd go for the portable 'c' solution if I wasn't squeezed for performance.