21 May 2021, 22:27 | #181 | |
Registered User
Join Date: Mar 2016
Location: Ozherele
Posts: 229
|
Quote:
It is sad that some people prefer to discuss empty matters instead of trying to help us find out the mystery about alignment timings that was discovered by modrobert. Last edited by litwr; 21 May 2021 at 22:34. |
|
21 May 2021, 22:33 | #182 | |
Registered User
Join Date: Mar 2016
Location: Ozherele
Posts: 229
|
Quote:
Code:
F00:0160 .longdiv F00:0161 if __VASM&28 ;68020/30? F00:0162 divul d4,d7:d3 F00:0163 else F00:0164 swap d3 S01:000000CE: 48 43 F00:0165 move d3,d7 S01:000000D0: 3E 03 F00:0166 divu d4,d7 S01:000000D2: 8E C4 F00:0167 swap d7 S01:000000D4: 48 47 F00:0168 move d7,d3 S01:000000D6: 36 07 F00:0169 swap d3 S01:000000D8: 48 43 F00:0170 divu d4,d3 S01:000000DA: 86 C4 F00:0171 F00:0172 move d3,d7 S01:000000DC: 3E 03 F00:0173 exg.l d3,d7 S01:000000DE: C7 47 F00:0174 clr d7 S01:000000E0: 42 47 F00:0175 swap d7 S01:000000E2: 48 47 F00:0176 endif F00:0177 move d7,(a3) ;r[i] <- d%b S01:000000E4: 36 87 F00:0178 bra.s .enddiv S01:000000E6: 60 1A F00:0179 F00:0180 if __VASM&28 ;68020/30? F00:0181 align 2 F00:0182 endif F00:0183 .l2 sub.l d3,d5 S01:000000E8: 9A 83 F00:0184 sub.l d7,d5 S01:000000EA: 9A 87 F00:0185 lsr.l d5 S01:000000EC: E2 8D F00:0186 .l4 F00:0187 if MULUopt F00:0188 moveq.l #0,d0 ;MULU optimization F00:0189 endif F00:0190 move -(a3),d0 ; r[i] S01:000000EE: 30 23 F00:0191 if MULUopt F00:0192 move.l d0,d1 ;MULU optimization F00:0193 lsl.l #3,d0 F00:0194 sub.l d0,d1 F00:0195 add.l d0,d0 F00:0196 sub.l d0,d1 F00:0197 sub.l d0,d1 F00:0198 lsl.l #8,d1 F00:0199 sub.l d1,d0 F00:0200 else F00:0201 mulu d1,d0 ;r[i]*10000 S01:000000F0: C0 C1 F00:0202 endif F00:0203 add.l d0,d5 ;d += r[i]*10000 S01:000000F2: DA 80 F00:0204 move.l d5,d3 S01:000000F4: 26 05 F00:0205 divu d4,d3 S01:000000F6: 86 C4 F00:0206 bvs.s .longdiv S01:000000F8: 69 D4 F00:0207 F00:0208 move d3,d7 S01:000000FA: 3E 03 F00:0209 clr d3 S01:000000FC: 42 43 F00:0210 swap d3 S01:000000FE: 48 43 F00:0211 move d3,(a3) ;r[i] <- d%b S01:00000100: 36 83 F00:0212 .enddiv F00:0213 subq #2,d4 ;i <- i - 1 S01:00000102: 55 44 F00:0214 bcc .l2 ;the main loop |
|
21 May 2021, 22:42 | #183 |
Registered User
Join Date: Mar 2016
Location: Ozherele
Posts: 229
|
|
21 May 2021, 23:05 | #184 | |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,408
|
Quote:
In a similar vein, it would be interesting to see what (if anything) can be gained by moving the 68K code into the first 64KB of memory (some instructions can be slightly faster in certain circumstances when they operate in/on the lowest 64KB). Not really in the spirit of the challenge, more of curiousity on my part Last edited by roondar; 22 May 2021 at 01:38. |
|
21 May 2021, 23:55 | #185 | |
Registered User
Join Date: Jan 2008
Location: Warsaw/Poland
Age: 55
Posts: 1,959
|
Quote:
|
|
22 May 2021, 00:46 | #186 |
Registered User
Join Date: Jan 2008
Location: Warsaw/Poland
Age: 55
Posts: 1,959
|
Let explain, theoretical D6 maximum can be $10000 (because your 64 KB RAM rules).
next move.l d6,d4 subq.l #1,d4 ; D4 can be max $FFFF next divu.w d4,d3 bvs.s .longdiv When overflow here can occured? Maybe for D4 values from $8000 to $FFFF? No, only for small D4 values and big D3 values. D3 must be higher than $8000000, for problems. Of course, i asked before how many times overflow occured and for which D4 and D3 values. But no answer. |
22 May 2021, 01:06 | #187 |
Registered User
Join Date: Jan 2008
Location: Warsaw/Poland
Age: 55
Posts: 1,959
|
And dont wrote more nonsenses, which instruction is valid or not valid for 68k. lsr.l D5 is NOT VALID instruction. If something is assembled then this is not equal then this is valid instruction.
For example some assemblers/compilers assembled f.e this btst #14,(A0) Maybe this is valid 68k instruction? But btst #14,D0 is VALID instruction. Maybe you see that first worked at memory and second on register? Good assembler can learn users which instruction is valid and which is not valid. For example AsmOne assembled bsr.l as bsr.w for 68000 without warning about not valid 68000 instruction. DevPac gave warnings |
22 May 2021, 01:40 | #188 |
Registered User
Join Date: Jan 2008
Location: Warsaw/Poland
Age: 55
Posts: 1,959
|
Shortest version for test.
Code:
.longdiv lsr.l #1,D3 divu.w D4,D3 move.w D3,D7 clr.w D3 swap D3 addx.w D3,D3 add.l D7,D7 exg D3,D7 move.w D7,(A3) ;r[i] <- d%b bra.b .enddiv |
22 May 2021, 04:33 | #189 |
Registered User
Join Date: Jan 2008
Location: Warsaw/Poland
Age: 55
Posts: 1,959
|
If previous version of longdiv works, then prefinal version of pi routine can looks next:
Code:
clr.l -(SP) ; cv moveq #0,D7 .l0 clr.l d5 ;d <- 0 move.l d6,d4 ;i <- kv, i <- i*2 adda.l d4,a3 subq.l #1,d4 ;b <- 2*i-1 move.w #10000,d1 bra.b .l4 .l2 sub.l d3,d5 sub.l d7,d5 lsr.l #1,d5 .l4 move -(a3),d0 ; r[i] mulu.w d1,d0 ;r[i]*10000 add.l d0,d5 ;d += r[i]*10000 move.l d5,d3 lsr.l #1,D3 divu.w d4,d3 move.w d3,d7 clr.w d3 swap d3 addx.w D3,D3 add.l D7,D7 exg D3,D7 move.w D7,(A3) ;r[i] <- d%b subq.w #2,d4 ;i <- i - 1 bcc.b .l2 ;the main loop divu.w d1,d5 ;removed with MULU optimization add.w (SP),D5 ; cv move.l D5,(SP) ; cv ext.l D5 ; necessary only for litwr version of PR0000 routine bsr PR0000 sub.w #28,d6 ;kv bne.b .l0 addq.l #4,SP ; restore stack |
22 May 2021, 05:44 | #190 | |||
Registered User
Join Date: Jun 2016
Location: europe
Posts: 1,039
|
Your words:
Quote:
Quote:
Yes, assemblers can do whatever they want, I *said* that. Why? Because they're always right? No, as I said, because they typically go for back/cross/whatever compatibility, so you don't have to go through thousands of lines of code and fix and review every single thing someone else at some point considered OK. And coming out of 8-bit era when some CPus could shift/rotate only 1 bit, it's not hard to understand why someone thought it's "good" to accept that as valid syntax. Quote:
LSL, LSR Logical Shift LSL, LSR <============================================= (M68000 Family) Instruction Format: MEMORY SHIFTS Instruction Fields: dr field—Specifies the direction of the shift. 0 — Shift right 1 — Shift left Effective Address field <============================================= Specifies the operand to be shifted. Only memory alterable addressing modes can be used as listed in the following tables: *Can be used with CPU32. 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 1 1 1 0 0 0 1 dr 1 1 EFFECTIVE ADDRESS MODE REGISTER Addressing Mode Mode Register Addressing Mode Mode Register Dn — — <============================================= An — — ... You are spinning *EVERYTHING* once you've been proven wrong, and then keep doing it over and over again until everyone gives up proving you wrong for the Nth time. It's the same as in your old x86 vs. Moto or whatever it was thread that eventually got closed or not, I don't even remember. Last edited by a/b; 22 May 2021 at 05:49. |
|||
22 May 2021, 13:10 | #191 | |
Computer Nerd
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 47
Posts: 3,751
|
Quote:
Removing this limit it crucial if you want to use this Pi spigot as a benchmark. Artificially limiting the more powerful systems just makes them look less powerful than they are. A good benchmark doesn't play favorites. |
|
22 May 2021, 13:39 | #192 |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,408
|
That was more or less my point, but to be fair here - you could also look at it as a benchmark for memory constrained operation on such systems. This can be a valid test, as long as everyone understands that's what's being done.
|
22 May 2021, 15:10 | #193 | |
move.l #$c0ff33,throat
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,863
|
Quote:
ASM-One gives a warning if CPU is set to 68000. Last edited by BippyM; 01 June 2021 at 18:24. |
|
22 May 2021, 15:18 | #194 |
Computer Nerd
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 47
Posts: 3,751
|
Memory isn't really restrained on such systems compared to 8 bit systems. Even on an A500 you have over 400 kb if you boot without an OS, so is this even relevant? Seems more interesting if the benchmark applies to real world setups and not artificially restrained ones.
|
22 May 2021, 15:46 | #195 |
Registered User
Join Date: Jan 2008
Location: Warsaw/Poland
Age: 55
Posts: 1,959
|
|
22 May 2021, 16:06 | #196 |
Registered User
Join Date: Jan 2008
Location: Warsaw/Poland
Age: 55
Posts: 1,959
|
2 bytes shortest version.
Code:
clr.l -(SP) ; cv moveq #0,D7 .l0 clr.l d5 ;d <- 0 move.l d6,d4 ;i <- kv, i <- i*2 adda.l d4,a3 subq.l #1,d4 ;b <- 2*i-1 move.w #10000,d1 bra.b .l4 .l2 sub.l d3,d5 sub.l d7,d5 sub.l d7,d5 lsr.l #1,d5 .l4 move.w -(a3),d0 ; r[i] mulu.w d1,d0 ;r[i]*10000 add.l d0,d5 ;d += r[i]*10000 move.l d5,d3 lsr.l #1,D3 divu.w d4,d3 move.w d3,d7 clr.w d3 swap d3 addx.w D3,D3 move.w D3,(A3) ;r[i] <- d%b subq.w #2,d4 ;i <- i - 1 bcc.b .l2 ;the main loop divu.w d1,d5 ;removed with MULU optimization add.w (SP),D5 ; cv move.l D5,(SP) ; cv ext.l D5 ; necessary only for litwr version of PR0000 routine bsr PR0000 sub.w #28,d6 ;kv bne.b .l0 addq.l #4,SP ; restore stack |
22 May 2021, 17:28 | #197 | ||||||
Registered User
Join Date: Mar 2016
Location: Ozherele
Posts: 229
|
Quote:
Quote:
Yes, this matter stopped saimo's last optimization. Quote:
D3 may be odd. So your code is wrong again. IMHO you would better find another occupation. The pi-spigot does something wrong for you. Quote:
Quote:
Quote:
Have you read several previous posts? It seems no. Let me repeat for you, more digits mean different data types and impossibility to test 8-bit systems and even some 16-bit systems. And I never claim my little project as a perfect benchmark. |
||||||
22 May 2021, 17:57 | #198 | |
Registered User
Join Date: Jan 2008
Location: Warsaw/Poland
Age: 55
Posts: 1,959
|
Quote:
Really D3 can be odd? Whow, surprise for me. But maybe you can learn something new about 68000 coding. How works addx.w D3,D3 What is wrong with ? btst #14,(A0) Think about this or check 68000 asembler book. |
|
22 May 2021, 18:11 | #199 | |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,408
|
Quote:
Before I do though, please understand that I haven't actually looked at your code in detail, so it may very well be that this method won't work in this case. It all depends on what kind of addressing modes you've used throughout. For example, if you access memory exclusively through address registers or via PC relative code, then there will be no gain. Also, this isn't really an Amiga optimisation as much as a 68000 optimisation: it should not hurt 68020+, but won't help them either. If it's applicable for your program, all 68000 versions could benefit (at the cost of requiring some or all of the code/data to be in the first 64KB of RAM, which may end up not being feasible). It's all based on this part of the Effective Address calculation cost diagram (source I've used for all timings given: http://oldwww.nvg.ntnu.no/amiga/MC68...000timing.HTML. I've verified they are the same as the timings found in the Motorola 68000 user manual, where they can be found on pages 8-2 and 8-8) Code:
memory Byte,Word Long xxx.W absolute short 8(2/0) 12(3/0) xxx.L absolute long 12(3/0) 16(4/0) Code:
instr xxx.W xxx.L JMP 10(2/0) 12(3/0) JSR 18(2/2) 20(3/2) LEA 8(2/0) 12(3/0) dn MOVE.W xxx.W 8 MOVE.W xxx.L 12 |
|
22 May 2021, 18:37 | #200 |
Computer Nerd
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 47
Posts: 3,751
|
I wasn't talking about more digits, I was talking about memory constraints. Two different things. Not having memory constraints enables more optimizations such as using a table for converting to decimal digits for example.
Perfect might be a little hard, but still, artificial limitations make the whole thing unfair right from the start, defeating the point. |
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 |
|
|