English Amiga Board - View Single Post

litwr · 19 August 2018, 19:52

Hi, friends! Sorry for a bit later reply - I have been a bit busy this week.

Sorry that some of my points look a bit unoptimal for somebody. However they all are based on my experience and common unbiased facts. It is well known fact that x86 family processors still have the best code density. x86-64 are not so good for this. I don't know why the code for HOMM2 for x86 could be larger in size than the code for 68000. I can only speculate that the code for x86 was written to support several graphic and sound cards. It is also quite possible that x86 version has more maps, etc. I have played it with x86 PC only. IMHO HOMM3 is much better and worth a realease in 2015! We can play it using Steam with modern x86 OS.
A lot of x86 instructions have odd length in bytes, 68000 has to use only even length for any of its instructions - this fact reduces the code density very much.
"The CLR problem is implementation bug and has nothing to do with the ISA's quality." Users of 68000 were forced to use CPU with this bug and they didn't have an alternative to use a corrected CPU.
"Address registers don't need to load 4 bytes (not always)." I don't understand this. If we want to set up an address register we have to load 4 bytes into it - and there is no alternative.
"bare 68000 is still faster than 80286" It sounds as a complete oddity for me. Try to find out benchmarks of the 80s, for example, https://archive.org/stream/byte-maga.../n247/mode/2up - it shows that PC XT with 8088 @4.77 MHGz is faster than Mac with 68000, and even 6502 @2MHz could beat 68000 at effective 6 MHz. 80286 is 3-4 times faster than 8088.
"Actually, one of the worse." My story is an emotional one so I have just expressed my feelings. I like 68000 too but I like truth and facts much more. Indeed 68000 is in some way more aesthetic.
XADD can be very useful as an atomic operation - https://en.wikipedia.org/wiki/Fetch-and-add
You can use OR R,R instead of TST R.
Anyway thanks for your words in this very interesting for me discussion.
EDIT. "There are relative modes, especially 16-bit PC-relative mode which x86 lacks." Those modes can help to make more compact and fast object file code but they mean not much for the executing code. x86 has relative jumps...

19 August 2018, 19:52	#16
litwr Registered User Join Date: Mar 2016 Location: Ozherele Posts: 229	Hi, friends! Sorry for a bit later reply - I have been a bit busy this week. Sorry that some of my points look a bit unoptimal for somebody. However they all are based on my experience and common unbiased facts. It is well known fact that x86 family processors still have the best code density. x86-64 are not so good for this. I don't know why the code for HOMM2 for x86 could be larger in size than the code for 68000. I can only speculate that the code for x86 was written to support several graphic and sound cards. It is also quite possible that x86 version has more maps, etc. I have played it with x86 PC only. IMHO HOMM3 is much better and worth a realease in 2015! We can play it using Steam with modern x86 OS. A lot of x86 instructions have odd length in bytes, 68000 has to use only even length for any of its instructions - this fact reduces the code density very much. "The CLR problem is implementation bug and has nothing to do with the ISA's quality." Users of 68000 were forced to use CPU with this bug and they didn't have an alternative to use a corrected CPU. "Address registers don't need to load 4 bytes (not always)." I don't understand this. If we want to set up an address register we have to load 4 bytes into it - and there is no alternative. "bare 68000 is still faster than 80286" It sounds as a complete oddity for me. Try to find out benchmarks of the 80s, for example, https://archive.org/stream/byte-maga.../n247/mode/2up - it shows that PC XT with 8088 @4.77 MHGz is faster than Mac with 68000, and even 6502 @2MHz could beat 68000 at effective 6 MHz. 80286 is 3-4 times faster than 8088. "Actually, one of the worse." My story is an emotional one so I have just expressed my feelings. I like 68000 too but I like truth and facts much more. Indeed 68000 is in some way more aesthetic. XADD can be very useful as an atomic operation - https://en.wikipedia.org/wiki/Fetch-and-add You can use OR R,R instead of TST R. Anyway thanks for your words in this very interesting for me discussion. EDIT. "There are relative modes, especially 16-bit PC-relative mode which x86 lacks." Those modes can help to make more compact and fast object file code but they mean not much for the executing code. x86 has relative jumps... Last edited by litwr; 19 August 2018 at 19:59.