<Maloeran> Could it be so the beginning of a text section is always aligned on a 4/8/16/32/64 bytes boundary?
<Maloeran> Preserving 16 bytes alignment would be sensible so that optimisation for branch prediction units work properly
<siz> ooh, good call ...hang on, calculating ... :)
* edcba has joined #asm
<Maloeran> 0xCC is probably used because that's not a valid x86 instruction ( I think )
<Maloeran> Therefore, if execution tries to go beyond the text segment, you'll get a SIGILL
<Maloeran> Or the windows equivalent signal
<siz> maloeran; it looks like they are there for the padding ... a friend of mine is also confirming we're looking at the same thing :)
<Maloeran> :) Right, makes sense
<siz> maloeran; out of curiosity, can you tell me why the padding's important for "branch prediction" ?
<siz> i assume branch predicition is an assembler optimization of sorts?
<Maloeran> For many reasons. Branch prediction units can only handle a certain number of branches per block of X bytes
<siz> where is branch prediction handled? in the operating system, or in the CPU/hardware?
<Maloeran> Plus, it's recommended that jump or call targets be aligned on a cache line boundary
<Maloeran> In the processor
* siz nods ...