13 July 2011, 17:59 | #41 | |||||
Registered User
Join Date: Jan 2008
Location: Warsaw/Poland
Age: 56
Posts: 2,039
|
Quote:
Quote:
Quote:
Quote:
Quote:
Last edited by Don_Adan; 13 July 2011 at 18:18. |
|||||
13 July 2011, 18:08 | #42 |
Registered User
Join Date: Jan 2008
Location: Warsaw/Poland
Age: 56
Posts: 2,039
|
If you want I can give you my full resource of ROM 3.0 and 3.1 in .ASM and .RS format. You can try to beat Cosmos attempts :-) I think that some ROM parts fully converted and debugged to ASM can be useful, f.e. scsi.device, 2nd.scsi.device, file systems (FFS) etc. I can help you with code optimisation too and some other easy coder jobs.
|
13 July 2011, 21:31 | #43 | |||||
Registered User
Join Date: Apr 2005
Location: digital hell, Germany, after 1984, but worse
Posts: 3,385
|
@Don_Adan
>>...the resulting executable should be 100% identical with the original after adjusting the hunk order and the RELOC handling.... Quote:
Sorry, but I don't use these assemblers, I still prefer to compile with the good old PhxAsm from Frank Wille, although he has already released his new assembler Vasm together with Volker Barthelmanns VBcc many years ago. PhxAsm has only a very few bugs, like sometimes calculating wrong distances to labels, but very rarely. And if it produces the wrong layout for the executable and the wrong Reloc order then I compile just an object file with PhxAsm first and generate the final executable with PhxLnk, which has more options to adjust these things correctly. I use AsmOne or AsmPro only sometimes as a memory monitor. For disassembling, my favourite tools are ADis, D68k and the interactive In_Go disassembler, probably that one that Cosmos uses, too. They all have some advantages and some drawbacks, none of them is perfect. So, the best is to compare their results and sometimes merge the code together. Quote:
Alright, it seems that we have a different interpretation of what an "executable" is. Your idea is that it must be an instruction or command that can be executed directly from DOS, right? I don't want to say that your point of view is wrong, but when I'm talking about an executable it can also be a library or a device driver, everything that contains some sort of executable code, like functions that can be called from any process. Quote:
Maybe these assembler are buggy, I don't know. But if the resulting output differs then it's your job as a programmer to compare it with the opcodes in the Programmer's Reference Manual from Motorola. Quote:
WinUAE is an excellent Amiga emulator and a lot of people are using it nowadays. If there are no drawbacks for 68020+ users then I always try to avoid WORD access and use LONG instead in order to improve the WinUAE performance, since that is the only system I use. The Amiga ROM is emulated too, of course, with the same benefit from long instructions. Quote:
No, I regret, but I guess I'm not a good translator and even more important is, I really hate to play any games! However, maybe someone else is ambitious enough to do this job. Good luck. |
|||||
13 July 2011, 22:12 | #44 | |
Banned
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
|
Quote:
A full 32 bit "long" operation is faster on modern pipelined 32 bit processors than 16 bit or 8 bit operations. This includes the 68060 and future fpga 68k processors. The long add.l d0,d0 instruction is not any bigger than add.w d0,d0 either. AmigaOS 3.9 no longer supports the 68000 so this optimization looks like a good combination of speed and size optimizing for 68020+ to me. Last edited by matthey; 13 July 2011 at 22:20. |
|
14 July 2011, 06:21 | #45 | ||
Banned
Join Date: Jan 2007
Location: France
Posts: 655
|
Some WIP report : beautifull optimisations are done using inlinined tiny subroutines
Original function from the v40.3 Quote:
Now in the v40.4 Quote:
This function is now shorter, without some bsr, and use less registers ! More than two times quicker ! I started this dos.library to enhance the A600/A1200 scsi.device... HD/CF access in general will be even faster ! (Before don't-know-what-you-are-talking-about messages, this library is not patch-able. All internal calls are done with bsr or jsr (PC), no jsr jmptable(a6). Check by yourself with the v39.23 (Kickstart 3.0) : http://eab.abime.net/showpost.php?p=766262&postcount=21 The v40.3 (Kickstart 3.1) is near equal) Last edited by Cosmos; 14 July 2011 at 07:14. |
||
14 July 2011, 12:42 | #46 | |||||
Registered User
Join Date: Jan 2008
Location: Warsaw/Poland
Age: 56
Posts: 2,039
|
Quote:
Quote:
Quote:
Quote:
Quote:
Tell me how many cycles takes add.w D0,D0 and add.l D0,D0 for 68040 and 68060? One or two? Perhaps you know that optimisation (if no special version for every CPU is created) is done always for the slowest CPU, not for the fastest. For 68000 add.w D0,D0 takes 4 cycles and add.l D0,D0 takes 6 cycles. Finally no big difference for 68040/68060, but for 68000 it can be difference in speed. Last edited by TCD; 14 July 2011 at 13:45. |
|||||
14 July 2011, 12:57 | #47 | |
Registered User
|
Quote:
|
|
14 July 2011, 14:41 | #48 | ||
move.l #$c0ff33,throat
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,863
|
Quote:
Quote:
I can nothing but agree here too, it's exactly the same for me. |
||
14 July 2011, 14:52 | #49 |
Banned
Join Date: Jan 2007
Location: France
Posts: 655
|
dos.library v40.4 beta 2 (38 664 bytes)
- All tables %0x00 aligned to keep 68000/010 happy (cnop 0,4) - fix four wrong arg registers (R_ExNext and some R_SetIoErr) - RomTag at the top beginning of the library - Correct EndMarker - Some small subroutines inlined - R_CurrentDir optimised - R_SetArgStr optimised - R_SetProgramDir optimised - 1468 bytes saved Always waiting for mfilos's feedbacks. So, still don't know is some usefull code were deleted in the beta 1. I think no, but maybe... Last edited by Cosmos; 16 July 2011 at 16:13. |
14 July 2011, 15:12 | #50 |
Registered User
Join Date: Mar 2009
Location: UK
Posts: 17
|
Thanks, I'll try them out over the weekend.
Do you have any performance benchmarks yet? Are you expecting any increases? I'll try and confirm if my pink screen is down to the latest graphics lib as well. |
14 July 2011, 15:22 | #51 |
Banned
Join Date: Jan 2007
Location: France
Posts: 655
|
>Are you expecting any increases?
No, too early beta for the moment... |
14 July 2011, 15:24 | #52 |
Paranoid Amigoid
Join Date: Mar 2008
Location: Athens/Greece
Age: 45
Posts: 1,978
|
Just tested it out:
Scenario 1: BB2 Exec.library but new Graphics.library + Dos.library b2 - CF booting into Classic WB 3.9 --> Result: Red screen + Reboots - No CF inserted but booting WB3.1 Floppy --> Result: Red screen + Reboots - No CF inserted --> Result: Normal kickstart screen with "3.9 ROM 45.057" ID. Scenario 2: Exec.library 45.24, stock 3.1 Graphics.library + Dos.library b2 - CF booting into Classic WB 3.9 --> Result: Black Screen - No CF inserted but booting WB3.1 Floppy --> Result: Black Screen - No CF inserted --> Result: Normal kickstart screen with "3.9.1 Rom 45.074" ID. Both scenarios tested under WinUAE with a clone configuration of my A600/030 setup. When I'll go home I can test it on the real hardware as well. Both scenarios tested as before but with the stock 3.1 Dos.library boot and work just fine. It could be a problem with the patched WB of mine... but since it doesn't boot with floppy there are either MODULES that don't like each other on my custom ROM, or something's wrong with the Dos.library. |
14 July 2011, 15:30 | #53 | ||
Banned
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
|
Quote:
http://www.heywheel.com/matthey/Amiga/ADis.lha http://aminet.net/dev/asm/ira.lha Quote:
|
||
14 July 2011, 15:36 | #54 | ||
move.l #$c0ff33,throat
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,863
|
Quote:
Quote:
Not true. If you hardcore optimize for 68030 f.e. the code will run much slower on 68060. |
||
14 July 2011, 16:14 | #55 | ||||
Registered User
Join Date: Jan 2008
Location: Warsaw/Poland
Age: 56
Posts: 2,039
|
Quote:
Quote:
Quote:
PM sent. Quote:
Last edited by TCD; 14 July 2011 at 16:24. |
||||
14 July 2011, 16:21 | #56 |
move.l #$c0ff33,throat
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,863
|
|
14 July 2011, 18:09 | #57 | |
Registered User
Join Date: May 2011
Location: Funeralopolis
Posts: 91
|
Quote:
|
|
14 July 2011, 22:29 | #58 |
The 1 who ribbits
|
I`m for the open source project, where many eyes my help the development time, after all we all want the same thing, A Better Amiga Experience
|
15 July 2011, 02:13 | #59 | |||
Banned
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
|
Quote:
Quote:
Quote:
mov.l <ea>,d0 Execute_result = d0 add.l d0,d1 A = d0 In the third (this) example, the result of the pOEP operation is needed as an input to the sOEP.IEE, but since the pOEP is executing the register-load MOVE instruction, the destination operand can be routed to the sOEP before the actual “execution” of the pOEP instruction. The test succeeds in this example. Kalms touches on this subject and gives a pretty good explanation toward the end of this thread... http://eab.abime.net/showthread.php?t=58743 Last edited by matthey; 15 July 2011 at 02:19. |
|||
15 July 2011, 09:15 | #60 | |
Banned
Join Date: Jan 2007
Location: France
Posts: 655
|
Quote:
A silly question : functions (declared in the jmptable) must be long-aligned (I don't want any cycles lost on 000/010) ?? |
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Open-source dos.library | Don_Adan | Coders. System | 273 | 02 September 2020 00:42 |
execute function from dos.library | Foul | Coders. Asm / Hardware | 5 | 08 August 2012 17:56 |
dos.library Open() hangs | MrD | Coders. Asm / Hardware | 15 | 24 July 2012 19:55 |
graphics.library 40.25 beta series | Cosmos | Coders. General | 337 | 22 July 2011 18:15 |
Dos.library question. | Thorham | Coders. General | 2 | 11 January 2011 21:03 |
|
|