@Gav,
On the Motorola 68000, a "feature" of the CPU prevented a dataread on an odd address. If you attempted to jump to an odd address, or read data from an odd address, you would generate a bus exception and then it's game over. The later generation CPU's (68020, 030, 040, 060) fixed this probelm, but you had to keep it in mind.
This lack of an ability to read an odd address caused problems within data structures. Suppose you had a byte field. Storing it within a struct is no problem, but what of the next fied within the struct? If you put it right next to the byte, the rest of the struct would be out of alignment. The compiler would pack out the struct with extra bytes to ensure proper alignment.
Get an Intel spec book. It gives you precise timings of the various instructions.
Back in the old days, when writing a game loop, we would write out all the opcodes we intended to use, then work out the time it takes for the game loop to execute. Different combinations of instructions would take different times. On the Z80, for example, it had these wonderful instructions LDIR and LDDR. They were one-shot data movers (moving up to 64k of data with a single instruction!), and had a number of useful features. Under some circumstances, though, it was faster to manually move a few bytes with a regular loop (or regular move instructions) than with LDxR. There was the setup, as you needed the B/C, D/E and H/L registers, and the storage of information contained within those registers, so this had to be factored in.
Since LDxR was a atomic instuction, it had the interesting problem that interrupts were essentially disabled during execution. No problem for small data moves, a major issue for big moves. You were better off breaking the moves up into smaller moves, after first working out the timing.
A lot of this isn't as important today as it once was, but with the rise of pixel shaders and other fun things, taking into account the speed of execution is becoming important again.
Neil
I have written machine code programs but I have never heard of the term "code alignment"?
On the Motorola 68000, a "feature" of the CPU prevented a dataread on an odd address. If you attempted to jump to an odd address, or read data from an odd address, you would generate a bus exception and then it's game over. The later generation CPU's (68020, 030, 040, 060) fixed this probelm, but you had to keep it in mind.
This lack of an ability to read an odd address caused problems within data structures. Suppose you had a byte field. Storing it within a struct is no problem, but what of the next fied within the struct? If you put it right next to the byte, the rest of the struct would be out of alignment. The compiler would pack out the struct with extra bytes to ensure proper alignment.
I disagree time to execute=number of instructions executed
Get an Intel spec book. It gives you precise timings of the various instructions.
Back in the old days, when writing a game loop, we would write out all the opcodes we intended to use, then work out the time it takes for the game loop to execute. Different combinations of instructions would take different times. On the Z80, for example, it had these wonderful instructions LDIR and LDDR. They were one-shot data movers (moving up to 64k of data with a single instruction!), and had a number of useful features. Under some circumstances, though, it was faster to manually move a few bytes with a regular loop (or regular move instructions) than with LDxR. There was the setup, as you needed the B/C, D/E and H/L registers, and the storage of information contained within those registers, so this had to be factored in.
Since LDxR was a atomic instuction, it had the interesting problem that interrupts were essentially disabled during execution. No problem for small data moves, a major issue for big moves. You were better off breaking the moves up into smaller moves, after first working out the timing.
A lot of this isn't as important today as it once was, but with the rise of pixel shaders and other fun things, taking into account the speed of execution is becoming important again.
Neil