Lpc2000

This indeed came up a while ago. 

To recap:

The reason bit-fields are a bad idea for hardware register access, is 
that it is completely undefined in ANSI 'C' as to how they are mapped 
to memory (which in turn is mapped to a hardware register). Bottom 
line: it may work, or it may not.

Even if you verify that the complier is doing what you expect by 
looking at the assembler output, it can change (an obvious change is 
if you change the optimisation setting on the compiler, or move to a 
new version of the compiler, or move to a new compiler, etc. etc.). 
You're faced with having to check every time you do a change like 
this. Fine if your happy to do this, but...

An exception to this is where particular copilier vendors (IAR? 
Keil?) have provided some degree of built-in support, where they 
essentially guarentee if you use the defined mechanism for accessing 
hardware registers that it'll work OK.

A standard way of accessing (reliably) hardware registers, is 
something like the following, which will work with any ANSI 'C' 
compiler (given the correct type definition to get the right register 
size):

/* define a 32-bit object */

typedef unsigned int uint32;

/* MACRO to access hardware registers: note the use of volatile to 
avoid compiler optimising out the access */

#define REG(addr) (*(volatile unsigned uint32 *)(addr))

/* define the register address */

#define GPIO_IOSET0        (0xE0028004)

/* set a particular bit position */

REG(GPIO_IOSET0) = (1 << bit_position);

/* can also be used to read a particular bit(s) */

if (REG(GPIO_IOPIN0 & bit_pos))
{
   /* bit set in here */
}
else
{
   /* bit clear in here */
}

It's not clear whether the original questioner on this topic wanted 
to maintain the same source code to run on both 8085 and LPC2000 
(which will be tough, however it's done) or just to use it as a 
starting point (a lot easier: some combination of global search and 
replace and use of the pre-processor should do the trick).

Hope this helps.

Brendan