View Single Post
Old 05 August 2016, 23:22   #19
matthey
Banned
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
Quote:
Originally Posted by Mrs Beanbag View Post
The subject of disassembling Frontier happened to come up at work today (i love my job) and apparently the whole thing is PC relative despite being >600k in size, there are various jump tables in it.
Jump tables as several BSRs to a JMP? SAS/C generated these tables for 68000 code as there is no Bcc.L or BSR.L. They are slow and ugly but they do help to avoid RELOCS and reduce the code size a small amount. A 68020 version with RELOCS could have been much faster. I'm not trying to take anything away from David Braben's accomplishment as there were compromises to be made and the Amiga version is good.

Quote:
Originally Posted by Mrs Beanbag View Post
But, generally, as frustrating as it is to have to LEA label(PC),An whenever i want to write to static storage, that's pretty rare for me, it's usually just for reading constants. d32(PC) would be really useful though.
It is no more difficult to use an absolute location than a PC relative one. The performance and code size would be the same. The 68020 does allow (d32,PC) addressing with (bd,PC,Rn.Size*Scale). This addressing mode may be used by some compilers when (d16,PC) can't be but the instructions grow by 4 bytes in length when it happens. It is possible to add a new addressing mode which would use the last 4 bits of the full format extension word to allow (d20,PC) as well as all (d20,PC,Rn.Size*Scale) variations. This would save 2 bytes when it could be used making PC relative instructions the same size as absolute addressing with RELOCS. The encoding is not bad at all.

Quote:
Originally Posted by Mrs Beanbag View Post
As for the more complex addressing modes of the 68020+, memory indirect and all that... how useful really are they? I can think of some uses, but mostly in conjunction with JSR/JMP to implement VTables of polymorphic classes. A version of Jmp that reads its effective address instead of jumping to it could be useful then.

jsrm / jmpm d16(An) ; reads longword address pointed to by d16(An) and jumps to it

i.e. same as the following:
move.l d16(An),Am
jsr / jmp (Am)
The 68020 addressing modes are very versatile and can do what you want.

Code:
    jmp ([d16,An])
    jsr ([d16,An])
Without OoO, this reduces the chances of instruction scheduling placing an instruction between what would be 2 dependent instructions. They do save a register and sometimes give a smaller instruction though.

The 68020 address modes are good for OOP but OOP is bad for processor performance. Indirect branches are difficult for even modern processors to deal with.

Quote:
Originally Posted by Mrs Beanbag View Post
But the 68k branch encodings are another puzzle. Why is it even possible to branch to an odd address, if it cannot possibly be valid? Why didn't they simply use a 7-bit field instead of 8 and use the upper bit to indicate whether it is a short branch or a long one? Because then a long branch could be 24 bit, which is as big as the original 68k's address bus.
The 68k designers probably had OCD because most data in encodings is well organized and commonly 8, 16 or 32 bits. Data extensions are in multiples of 16 bits as the variable length encodings are multiples of 16 bits.
matthey is offline  
 
Page generated in 0.05195 seconds with 11 queries