11 September 2018, 17:36 | #481 |
Registered User
Join Date: Jun 2015
Location: Germany
Posts: 1,926
|
If you really want data on binary sizes, have a look at old linux distributions that were available for m68k and i386. Just pick a good sample of packages that include mostly executable code and have a look at the file sizes. I'm pretty sure that m68k will have better code density than i386. Of course, the result will be skewed by the unknown effects of gcc/i386 vs. gcc/m68k. Presumably the latter didn't get as much love.
Unfortunately this sort of information is difficult to find today on the internet. I looked around in debian online resources and didn't find anything that still had m68k packages and eventually lost interest. Perhaps one of you guys wants to pick it up... |
11 September 2018, 17:40 | #482 | |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,437
|
Quote:
Not all switches are compatible with this style, but you'd be surprised by how often it's possible to convert them into this type of indirect jump. |
|
11 September 2018, 17:47 | #483 | |||||||||
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,355
|
Not a problem, we've got more Mhz
Quote:
During that time more features could be added to 68000 address registers - which they unfortunately didn't do. Now I must add that x86's registers aren't GPR either. Are SI, DI, BP true GPR ? Nope. You can't byte access them, for example. In some way, they are... address registers Quote:
Quote:
Quote:
Quote:
I'm not sure boot block isn't still in 16-bit mode. Quote:
And it's true 68020 code is (slightly) smaller than 68000 code (while 80386 code is bigger than 8086). But the difference can't account for the *1.5 I regularly observed. Comparing byte-by-byte isn't necessary, just check where individual routines are located. And I know the entry point of many routines. Every time i checked, 68k code was smaller. Some little extract for you, with 6 different game versions (Mac 68k 1.0 en, PC 1.0 en, PC 1.0 fr, PC 2.0 fr, PC 2.1 en, PC 2.1 pl) : Code:
464e4 439190 49546b 43b7d4 423760 456ae0 GetRandomNumTroops__4gameFi 46b52 439865 495B40 43BEA9 423E50 457190 NextPlayer__4gameFv 46fd0 439E0E 4960EA 43C440 4243F0 4576C0 ComputeDailyGold__4gameFi 4744e 43A244 496520 43C872 424830 457A50 PerDay__4gameFv 47a90 43ABC4 496EA0 43D21C 4251E0 458460 PerWeek__4gameFv 48ad8 43C45C 498739 43ED56 426D20 45A0C0 PerMonth__4gameFv Do you observe at which speed the offsets (load address for windows code) grow ? It is clear that, while extra code has been added in later versions (not much), 68k code is indeed smaller. Actually this was a great surprise to me, because it's largely suboptimal, and, worse, linker names (the names you can see above) were present at the end of nearly every routine ! I doubt CodeWarrior for Mac in Debug mode did better than MSVC6 in Release mode, yet the code is smaller. If you don't believe me you can just get the exes (i probably even still have them) and disassemble the code yourself Quote:
Hmm... All of this is none too clear... Quote:
Quote:
Another reason for us to prefer code ? |
|||||||||
11 September 2018, 18:57 | #484 | |
Registered User
Join Date: Jan 2008
Location: Warsaw/Poland
Age: 56
Posts: 2,046
|
Quote:
Code:
subq.w #1,d0 bcs case_0 beq case_1 subq.w #2,d0 bcs case_2 case_3 ... case_2 ... case_1 ... case_0 ... |
|
11 September 2018, 19:16 | #485 |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,355
|
|
11 September 2018, 19:50 | #486 | |
Registered User
Join Date: Jan 2008
Location: Warsaw/Poland
Age: 56
Posts: 2,046
|
Quote:
For most cases next code is used as input: moveq #0,d0 move.b (a0)+,d0 but next code can be used too moveq #3,d0 and.b (a0)+,d0 Of course this is only example to remove extra branch check. Not for all cases can be used. |
|
12 September 2018, 12:53 | #487 |
Registered User
Join Date: May 2013
Location: Grimstad / Norway
Posts: 853
|
Talking to myself, but some groundwork has been done over at http://www.visual6502.org/images/pag...ola_68000.html
|
13 September 2018, 09:00 | #488 | |
Banned
Join Date: Sep 2016
Location: UK
Posts: 2,917
|
Quote:
|
|
13 September 2018, 09:52 | #489 | ||
Registered User
Join Date: Mar 2016
Location: Ozherele
Posts: 229
|
Quote:
Quote:
I'm really curious when will computers have about 4 exabytes of memory? I can think about 50 years forward - too much to me to see that. |
||
13 September 2018, 11:31 | #490 |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,437
|
Assuming the 1nm transistor suggested by Berkley is a thing that can work in the future, all you'd need for 4 exabytes of DRAM memory is a 283 square cm die. Back to room sized computers it is
|
13 September 2018, 13:01 | #491 | ||
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,355
|
Quote:
Anyhow, of course 8086 isn't good at 32-bit stuff Quote:
There are limits such as speed of electricity, ultimately speed of light, that could stop the exponential growth of computational power. |
||
13 September 2018, 13:18 | #492 | |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,355
|
Quote:
I had the algorithm noted somewhere so i tried recoding it for 68020 and got a 408 bytes executable (which can probably still be slightly reduced). Is there something the program must do that i forgot ? |
|
13 September 2018, 16:21 | #493 | |
Registered User
Join Date: Mar 2016
Location: Ozherele
Posts: 229
|
Quote:
|
|
13 September 2018, 16:32 | #494 |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,355
|
|
13 September 2018, 20:20 | #495 |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,355
|
Done it !
Executable rewritten for A1200, contains all features of the original (even speed ; could be shorter if i remove the mulu optim). Size = 596 bytes. x86 beaten But the added bulk is mostly AmigaOS calls. For this reason i don't see this program as significant in matter of code density as it depends as much on the host operating system as on the cpu. Nor is it relevant for cpu benchmark, as most of the time is spent displaying digits rather than calculating them... |
15 September 2018, 12:51 | #496 | ||
Registered User
Join Date: Mar 2016
Location: Ozherele
Posts: 229
|
Quote:
Quote:
BTW the part about the first 32-bit CPU is added to the article -https://litwr.livejournal.com/1970.html |
||
15 September 2018, 13:56 | #497 | ||
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,355
|
Quote:
Only SI can read with auto-increment. Only DI can write with auto-increment. Only BP can be used as frame pointer. Only DX can be used as loop counter with the loop instruction. Only CL can be used for variable shifting. There are numerous examples. x86 registers are definitely not GPR. Quote:
If we have to work with words the 68k can use the SWAP instruction and we can get up to 16 data. With extra instructions to access register parts, we could have access to up to 32 bytes. And it's not "plus 4 registers". Only 3, as SP can't be used for data. It seems there is a lot of misunderstanding about the D/A split of 68k. Many people see it as a shortcoming. But it's not. Not at all. The price to pay is very small for what we get. On cpus with 16-bit opcode we have 3-bit register encoding. This is necessary if you don't want to see the instruction set severely trimmed. On 68k you have the base encoding which is 4-bit opcode, 3-bit register, 1-bit mode, 2-bit size, 6-bit ea. If we want to use 4-bit register, that's +2 bits here (ea becomes 7-bit). It simply doesn't fit. On ARM (with Thumb) 16-bit opcodes can only touch R0-R7. On x86-64 you can not use R8-R15 without a REX prefix. But on 68k you can use all 16 registers without a size penalty. Try to multiply, divide, shift a pointer type with a C compiler. It will be rejected, and with good reason. Do people grumble that these operations are not allowed ? It's nonsense. As addresses are 32-bit, any 16-bit use is automatically extended. In addition, the resulting value is supposed to be pointer, not data, and therefore the CCR remains untouched. It's true sometimes we're out of data regs and start using address regs for data. But then we have more features, not less : automatic sign-extend and operations that don't alter the flags. Consider simple ADDA.W (A0,D0.W),A0. You can't do that on x86. You have to read the value, extend it, then add it. Of course x86's pointer arithmetic kills the flags and that's really bad. The only problem is that the use of An is too limited in comparison to what the encoding would allow - for the cases we indeed lack some Dn. However this could have been fixed. But in any case, don't judge without knowing. I don't like to keep attachments in my posts, but I can put it in the zone here, if you have access to it. |
||
15 September 2018, 14:57 | #498 | |||
Registered User
Join Date: Mar 2016
Location: Ozherele
Posts: 229
|
Quote:
Quote:
Quote:
EDIT. I agree that the 68k's address registers can be considered as limited data registers too. |
|||
15 September 2018, 15:24 | #499 | |||
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,355
|
Yes, and you ?
Wasn't that you, rather ? What I wrote is correct. The uses of SI, DI, DX i have written are correct and the fact i didn't mention DX as port number doesn't change that. Quote:
Anyway, according to your definition, 68k's registers are GPRs because they really can store both data and addresses (and the rest is "just about of absence of not-important orthogonality" ). But strange case for DX indeed, even though it's not exactly a memory address it needs to store (it's a port number - and remains 16-bit even in 32-bit mode). Also forgot to mention AX is the only register usable for a number of things. Quote:
Of course it makes the code bigger too Quote:
To access it : http://eab.abime.net/faq.php?faq=vb_...ezone_faq_item Tell me when you're ready. I'll upload it then. |
|||
20 September 2018, 15:27 | #500 |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,355
|
Not eager to get it, huh ? I won't wait any longer and have made the upload anyway. Other ppl might be interested.
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Any software to see technical OS details? | necronom | support.Other | 3 | 02 April 2016 12:05 |
2-star rarity details? | stet | HOL suggestions and feedback | 0 | 14 December 2015 05:24 |
EAB's FTP details... | Basquemactee1 | project.Amiga File Server | 2 | 30 October 2013 22:54 |
req details for sdl | turrican3 | request.Other | 0 | 20 April 2008 22:06 |
Forum Details | BippyM | request.Other | 0 | 15 May 2006 00:56 |
|
|