20 May 2021, 11:07 | #141 | |
Registered User
Join Date: Jan 2008
Location: Warsaw/Poland
Age: 56
Posts: 2,029
|
Quote:
|
|
20 May 2021, 11:57 | #142 | |
Registered User
Join Date: Dec 2010
Location: Athens/Greece
Age: 53
Posts: 720
|
Quote:
Basic Premise: (from troll's site) Every program is satisfying four restrictions: 1) it measures time; 2) it uses an OS function to print digits, it prints 4 digits a time synchronously with the calculation of them; 3) it uses less than 64 KB RAM for the code and data; 4) it utilizes all available RAM below 64 KB limit to get the maximum number of calculated digits, so it is forbidden to restrict artificially the maximum number of digits. Take note on 2. Use OS for print. I think it was Maynaf that suggested OS's RawDoFmt/Write a gazzilian years ago, but troll said it was not fair. So, use OS but don't use OS if the amiga has an advantage. It's pretty pointless, unless you want to keep feeding the troll though. My €0.02 |
|
20 May 2021, 12:12 | #143 | |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,436
|
Quote:
I'm not going to guess about the intentions here (they may be perfectly legitimate, they may not), but IMHO it's quite clear the stated limitations as is make the nature of the program not very good as a cross-platform benchmarking tool. Meaning, it won't really tell you all that much about real world performance differences because of these kind of specialised limitations. |
|
20 May 2021, 14:49 | #144 |
Registered User
Join Date: Jan 2008
Location: Warsaw/Poland
Age: 56
Posts: 2,029
|
On Amiga is no problem to write program which use full 64KB for store digits. But it will be unfair for 8bit systems and maybe some other CPU's.
|
20 May 2021, 19:10 | #145 | ||
Registered User
Join Date: Aug 2010
Location: Italy
Posts: 853
|
I'm sorry if this sounds pedant, but we should not spread wrong notions, especially when there is already some confusion.
Quote:
Please don't be fooled by the fact that the writing Assembler Syntax: MOVEQ # < data > ,Dn doesn't include ".l", as the same happens also with the other instructions - for example, here's move: Instructions without a size are explicitly declared unsized - here's an example: Quote:
|
||
20 May 2021, 19:25 | #146 |
Computer Nerd
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 48
Posts: 3,831
|
|
20 May 2021, 19:39 | #147 | |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,351
|
Quote:
That some "official" online doc says something does not change what is correct and what is not (btw. Freescale isn't Motorola as we knew it). No. Most, if not all, disassemblers, will output it without a size and all assemblers accept it without a size -- while you may eventually find some which reject moveq.l (and bset.b, etc). If assemblers rejected all 'wrong' syntax with this definition, not a single source in the world would assemble |
|
20 May 2021, 20:00 | #148 | |||
Registered User
Join Date: Aug 2010
Location: Italy
Posts: 853
|
Quote:
Quote:
Quote:
|
|||
20 May 2021, 20:12 | #149 | |||
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,351
|
Quote:
http://www2.ece.ohio-state.edu/~degr.../M68000PRM.pdf Quote:
Quote:
https://www.nextop.de/NeXTstep_3.3_D...mld/index.html |
|||
20 May 2021, 20:20 | #150 | |
Registered User
Join Date: Mar 2016
Location: Ozherele
Posts: 229
|
Quote:
BTW I have just checked LSL.L D5 with ASMONE - it works perfectly. |
|
20 May 2021, 20:24 | #151 | |
Registered User
Join Date: Mar 2016
Location: Ozherele
Posts: 229
|
Quote:
EDIT. And 140 cycles for DIVU is the worst case. 78 is the best. Last edited by litwr; 20 May 2021 at 20:40. |
|
20 May 2021, 20:28 | #152 |
Registered User
Join Date: Jun 2016
Location: europe
Posts: 1,053
|
If you look at moveq's opcode you will not find size bits. moveq is always .L and there is no point, in my opinion, to write .L, it's unambiguous. Same with, for example, lea. And since these instructions are so common and frequently used it should be common knowledge what they do and cut the c... size out. And the fact that eg. winuae debugger's craptastic disassembler spits out nonsense like bt instead of bra, lea.l, moveq.l etc, does not change that.
If you look at addq.w #n,ax and addq.l #n,ax, they do exactly the same thing. You could say there's no point in writing the size, but they don't have the same opcode (size is part of the opcode in this case) so it does matter. And finally... lsl dx does not have its own opcode, it's an alias for lsl #1,dx at best. lsl <ea> does exists, *but* you should not stop there, you should look at its <ea> table and you'll see that dx is not supported (eg. that specific opcode might be used to encode some other instruction). Thread moves fast... No, Moto doc *does* "forbid" lsl dx. Again, look at the <ea> table for lsl and you will see: Dn - You cannot just look at the first part of the information and then ignore the other, relevant, part. What assemblers accept or don't is another thing, they are typically written to accept all kinds of crap for back/cross/whatever compatibilty. |
20 May 2021, 20:32 | #153 | |
Registered User
Join Date: Mar 2016
Location: Ozherele
Posts: 229
|
Quote:
Code:
CNOP 0,4 Code:
ALIGN 2 We need help from the 68k experts for this issue. The 68k experts! Help us! I am completely baffled here. |
|
20 May 2021, 20:41 | #154 |
Registered User
Join Date: Jun 2016
Location: europe
Posts: 1,053
|
Use ALIGN 0,4.
I presume that ALIGN 2 is expanded to ALIGN 2,0, so it does no current address aligment (2nd argument is 0) and then adds 2 to the current address. Eg. it works the same only if the current address is not longword aligned (2, 6, 10, ...). |
20 May 2021, 21:24 | #155 |
old bearded fool
Join Date: Jan 2010
Location: Bangkok
Age: 56
Posts: 779
|
|
20 May 2021, 22:26 | #156 | |||
Registered User
Join Date: Aug 2010
Location: Italy
Posts: 853
|
Quote:
(Click to see in full size.) Quote:
(Click to see in full size.) Now, you're throwing in the mix two things I either didn't touch on or say: * Technically, moveq is 8->32, not 32 - that's right, but I didn't even remotely touch on that aspect; * we should write 'moveq.l' and not 'moveq' - nowhere I said that. Let's instead look at what actually happened. In post #140 you wrote: As an example, most assemblers will accept moveq.l even though it is technically incorrect (moveq has no size). With post #145 I showed that "moveq has no size" is false, as the official reference manual from Motorola (again, the same you linked to) states that the size of moveq is long; additionally, I showed an example on an instruction that actually has no size (bfextu). That's all there is to it, and I'm shocked that such a basic matter started such a reaction Regarding appending ".l" to "moveq": it's redundant, but not technically wrong, because the size attribute of moveq is precisely .l. But that's a totally different story from lsr.l d5: that is just wrong, because Motorola's syntax - and, even more, instruction encoding - demands that a count be specified when the operand is a register. Quote:
|
|||
20 May 2021, 22:27 | #157 | |||||||||
Registered User
Join Date: Mar 2016
Location: Ozherele
Posts: 229
|
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
However saimo and Don_Adan just tries to make the impossible. They pushed me to make some minor improvements which mean very little. Saimo also started this fruitless LSR D5 discussion. Quote:
Quote:
Quote:
Of course, these are only results for this particular algorithm. This is mostly the division benchmark. |
|||||||||
20 May 2021, 22:32 | #158 | |||
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,436
|
Quote:
Quote:
Quote:
|
|||
20 May 2021, 22:33 | #159 |
Registered User
Join Date: Mar 2016
Location: Ozherele
Posts: 229
|
The main loop starts from .longdiv label and it ends on the bcc .l2 statement. The main loops for 80286 and 68020 have the same size now.
|
20 May 2021, 22:37 | #160 | |||
Registered User
Join Date: Aug 2010
Location: Italy
Posts: 853
|
Quote:
Quote:
The only result you'll achieve by not accepting that your interpretation is wrong is that you won't learn something new and your reputation will be affected negatively. Quote:
|
|||
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
68020 Bit Field Instructions | mcgeezer | Coders. Asm / Hardware | 9 | 27 October 2023 23:21 |
68060 64-bit integer math | BSzili | Coders. Asm / Hardware | 7 | 25 January 2021 21:18 |
Discovery: Math | Audio Snow | request.Old Rare Games | 30 | 20 August 2018 12:17 |
Math apps | mtb | support.Apps | 1 | 08 September 2002 18:59 |
|
|