32bit CPU with 16bit software ?

[exxos]

I have no idea about the software side of all this...

For example on the Falcon, being 16bit access to ROM, if this was converted to 32bit access, would it be any faster anyway as the software running (TOS) would still only be running 16bit instructions ?

Also, I was plotting 32bit fast-ram on a 020 CPU, but would anything actually run at 32bit ?

Similar with ST-RAM, that could be converted to 32bit, but no idea how the software would run on such a system. I mean instead of a 16bit access to RAM, be it a low and high byte, a 32bit access, could access 4 bytes at once. But that would have to somehow equate that the upper 2 bytes would still have to be accessible on a 16bit access

[pixelpusher]

I have no idea about the software side of all this...

For example on the Falcon, being 16bit access to ROM, if this was converted to 32bit access, would it be any faster anyway as the software running (TOS) would still only be running 16bit instructions ?

Also, I was plotting 32bit fast-ram on a 020 CPU, but would anything actually run at 32bit ?

Similar with ST-RAM, that could be converted to 32bit, but no idea how the software would run on such a system. I mean instead of a 16bit access to RAM, be it a low and high byte, a 32bit access, could access 4 bytes at once. But that would have to somehow equate that the upper 2 bytes would still have to be accessible on a 16bit access

Usually as programmer you're expected to make int16 or int32 (or int64 these days) accesses properly aligned. If you don't, then Cisc cpus will usually add a penalty for every misaligned access (and on top you loose some implicit functionality - like integer mem operations being atomic), or on old Risc cpus a misaligned access (e.g. 32 bit with a "odd" 16 bit alignment) would simply crash.

Would 32 bit ST-Ram be (significantly) faster - I think that's a question you hw guys should be able to answer it depends on what the 68k (or newer) cpu does to load or store the data from memory. Does it wait for another four cycles for the second 16 bits, or can you just feed the cpu with one 32 bit access? I'd assume that this might be very differnt for 68k, 020, 030, etc. ...

On the software side, if you wanted to move data fast, you already either used larger blocks of move.l operations or movem.l operations (which could benefit from faster access - if you can load & store 32 bits in one access instead of two 16 bit ram accesses)

[stephen_usher]

The 68000 wouldn't be able to access 32 bit RAM directly anyway as it has a 16 bit data bus.

However the 68020/030 etc. can access a 32 bit bus directly. In the case of the 68030 with its data and instruction caches this would benefit processing, even if the instructions themselves are 16 bit as the cache can be filled with fewer read cycles.

[thorsten.otto]

would it be any faster anyway as the software running (TOS) would still only be running 16bit instructions ?

The instructions might be made up of 16bit words, but addresses aren't, and access to memory can still be 32bit. So yes, a 32bit bus will be faster. If i'm not wrong, that 16bit bus is one of the main bottlenecks on a falcon.

[mikro]

Also worth noting - full 32-bit bus enables usage of so called burst mode on the 030 (and higher), so you can fetch 16 bytes at once.