dos.library v40.4 beta series

[Don_Adan]

Originally Posted by PeterK

>>...the resulting executable should be 100% identical with the original after adjusting the hunk order and the RELOC handling....

No, exist many different version of 68K assemblers/compilers which uses different opcode for some commands, I known three different assemblers: ASMone, DevPac (GenAm) and Holger Gehrmann assembler. You can check f.e. Biing exe files, all relocs are in reverse rotation and some commands uses different opcode.

Originally Posted by PeterK

Hmm, what are you disassembling Don_Adan ?? Compressed pictures or databases ??
I thought we were talking about executables, like libraries, or don't we. Libraries usually start with a MOVEQ #-1,D0 and RTS to prevent direct execution..

I resourced many Amiga files (binary and exe), some Atari ST, a few Mac, SegaMegadrive and MAME (68k). DOS library is not executable file you can't easy compare this with original binary version, but of course size can be compared.

Originally Posted by PeterK

Different assemblers should not make different opcode as long as you switch all optimization options off when you're reproducing the reference version of the code..

Wrong, check DevPac and ASMOne output for this same source f.e. your library. I never use optimization, due has no sense for me and is only for very lazy coders.

Originally Posted by PeterK

Ok, maybe good for 68000, but WORD size is bad for WinUAE, because PCs always need an extra prefix byte for WORD access, and that's slower than LONG.

This is Amiga ROM, not PC ROM.

Originally Posted by PeterK

If you really built a 100% working reference library first before starting to change any code, as I tried to explain above, then there should be no hidden access left and you can even move some functions or pieces of code to other locations if you like. This should work as long as the code is not encrypted somehow.

No, thanks, I don't want to make Amiga library, but I can help, if someone ask. I like my hobby like ripping music, creating players and other easy job for coders. But if you want I can send to you german texts from Death Or Glory and you can translate text to english. I still can't finish english version of this game, due no german translator. All other works for this game is already done, f.e. main file is fully translated.

[Don_Adan]

Originally Posted by StingRay

So again: Why don't you open a public GIT/SVN repository so everyone can see your code?

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.

[PeterK]

@Don_Adan
>>...the resulting executable should be 100% identical with the original after adjusting the hunk order and the RELOC handling....

No, exist many different version of 68K assemblers/compilers which uses different opcode for some commands, I known three different assemblers: ASMone, DevPac (GenAm) and Holger Gehrmann assembler. You can check f.e. Biing exe files, all relocs are in reverse rotation and some commands uses different opcode.

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.

I resourced many Amiga files (binary and exe), ...

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.

Wrong, check DevPac and ASMOne output for this same source f.e. your library.

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.

This is Amiga ROM, not PC ROM.

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.

But if you want I can send to you german texts from Death Or Glory and you can translate text to english. I still can't finish english version of this game, due no german translator. All other works for this game is already done, f.e. main file is fully translated.

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.

[matthey]

Originally Posted by PeterK

Ok, maybe good for 68000, but WORD size is bad for WinUAE, because PCs always need an extra prefix byte for WORD access, and that's slower than LONG.

Originally Posted by Don_Adan

This is Amiga ROM, not PC ROM.

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.

[Cosmos]

Some WIP report : beautifull optimisations are done using inlinined tiny subroutines

Original function from the v40.3

R_GetCurrentDirName ; 54 bytes
movem.l d2-d3/a2-a3,-(sp)
move.l d1,a3
bsr.w R_Cli
move.l d0,a2
move.l a2,d0
bne.b JL_0_26CA6
bsr.w JL_0_20504
move.l d2,-(sp)
move.l d2,d3
move.l a3,d2
bsr.w R_NameFromLock
move.l (sp)+,d2
bra.b JL_0_26CB4
JL_0_26CA6
move.l 4(a2),d0
asl.l #2,d0
move.l d0,a0
move.l d2,d0
move.l a3,a1
bsr.b JL_0_26C36
JL_0_26CB4
movem.l (sp)+,d2-d3/a2-a3
rts

JL_0_26C36
movem.l d6-d7/a2-a3,-(sp)
...

Now in the v40.4

R_GetCurrentDirName ; 52 bytes
move.l 4.w,a0
move.l $114(a0),a0
move.l $5C+$50(a0),d0
lsl.l #2,d0
bne.b JL_0_26CA6
movem.l d2-d3,-(sp)
move.l d2,d3
move.l d1,d2
move.l $3C+$5C(a0),d1
bsr.w R_NameFromLock
movem.l (sp)+,d2-d3
rts

JL_0_26CA6
move.l d0,a1
move.l 4(a1),d0
asl.l #2,d0
move.l d0,a0
move.l d2,d0
move.l d1,a1

JL_0_26C36
movem.l d6-d7/a2-a3,-(sp)
...

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)

[Don_Adan]

Originally Posted by PeterK

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.

I don't know better 68K disassembler for Amiga than ReSource v6. All other "intelligent" resourcers are poor for good protected code or useless for binary files.

Originally Posted by PeterK

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.

No, executable file (for me) is every file with exe hunks (drivers, library too), but DOS library is not exe file, due no exe hunks. All other (without Amiga exe hunks) files are binary files (for me).

Originally Posted by PeterK

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.

I don't remember exactly, but differences exist f.e. for cmpi and cmp commands. Both commands works identical, but uses different opcode.

Originally Posted by PeterK

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.
.

For me always Amiga is first, PC is fast enough and even if lost a few extra cycles this is not big problem (for me).

Originally Posted by matthey

[/i]



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.

This is code from 3.1 ROM, not poor 3.9 ROM.
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.

[BuZz]

Originally Posted by Don_Adan

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.

I would be interested to have a look if I may ? Just for interest purposes. Thanks don

[StingRay]

Originally Posted by Don_Adan

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.

I'd like to have a look, yes. But I don't have much interest (nor time) to optimise/fix ROM routines. A fully disassembled (and commented) ROM source is a nice thing though.

Originally Posted by Don_Adan

I don't know better 68K disassembler for Amiga than ReSource v6. All other "intelligent" resourcers are poor for good protected code or useless for binary files.

I can nothing but agree. ReSource beats all other Amiga disassemblers by far (even though Cosmos once claimed InGo is the best...).

Originally Posted by Don_Adan

No, executable file (for me) is every file with exe hunks (drivers, library too), but DOS library is not exe file, due no exe hunks. All other (without Amiga exe hunks) files are binary files (for me).

I can nothing but agree here too, it's exactly the same for me.

[Cosmos]

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...

[JimmySage]

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.

[Cosmos]

>Are you expecting any increases?

No, too early beta for the moment...

[mfilos]

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.

[matthey]

Originally Posted by Don_Adan

I don't know better 68K disassembler for Amiga than ReSource v6. All other "intelligent" resourcers are poor for good protected code or useless for binary files.

Resource is probably still the "best" due to all it's options but ADis and IRA are often faster and easier to get some useful output for reassembling for example. Both have there advantages and have been improved. The version of ADis below is newer than the old version on Aminet.

http://www.heywheel.com/matthey/Amiga/ADis.lha
http://aminet.net/dev/asm/ira.lha

Originally Posted by Don_Adan

This is code from 3.1 ROM, not poor 3.9 ROM.
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.

moveq and add.l can both be done in 1 cycle on the 68060 due to result forwarding because moveq has a long output and add.l has a long input. moveq and add.w will take 2 cycles on the 68060. So the version with the add.l is twice as fast on the 68060. I don't optimize for the 68000. It's very different than 68020 and really hurts performance on 68020+. On the other hand, optimizing for 68020, 68030 and 68060 is very similar.

[StingRay]

Originally Posted by matthey

Resource is probably still the "best" due to all it's options but ADis and IRA are often faster and easier to get some useful output for reassembling for example.

I disagree totally. ReSource is not the best because it has so many options, it's the best because it has a GUI which makes it very easy to change data types/code etc. pp. Which in turn means that you can get a valid output much faster than with a shell only disassembler. And it's easier to use too.

Originally Posted by matthey

On the other hand, optimizing for 68020, 68030 and 68060 is very similar.

Not true. If you hardcore optimize for 68030 f.e. the code will run much slower on 68060.

[Don_Adan]

Originally Posted by matthey

Resource is probably still the "best" due to all it's options but ADis and IRA are often faster and easier to get some useful output for reassembling for example. Both have there advantages and have been improved. The version of ADis below is newer than the old version on Aminet.

http://www.heywheel.com/matthey/Amiga/ADis.lha
http://aminet.net/dev/asm/ira.lha



moveq and add.l can both be done in 1 cycle on the 68060 due to result forwarding because moveq has a long output and add.l has a long input. moveq and add.w will take 2 cycles on the 68060. So the version with the add.l is twice as fast on the 68060. I don't optimize for the 68000. It's very different than 68020 and really hurts performance on 68020+. On the other hand, optimizing for 68020, 68030 and 68060 is very similar.

Yes, moveq #$69,D1 and add.l D0,D0 can be done in one cycle for 68060, but moveq #$69,D0 and add.l D0,D0 can't be done in one cycle for 68060, if I remember right. For this example perhaps is not differences between add.l D0,D0 and add.w D0,D0, but I'm not 68060 expert.

Originally Posted by BuZz

I would be interested to have a look if I may ? Just for interest purposes. Thanks don

PM sent.

Originally Posted by StingRay

I'd like to have a look, yes. But I don't have much interest (nor time) to optimise/fix ROM routines. A fully disassembled (and commented) ROM source is a nice thing though.




I can nothing but agree. ReSource beats all other Amiga disassemblers by far (even though Cosmos once claimed InGo is the best...).




I can nothing but agree here too, it's exactly the same for me.

No comments in my resources.
PM sent.

Originally Posted by Cosmos

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...

Better use "even" or "cnop 0,2" than "cnop 0,4", due you often lost 2 bytes of ROM space.

[StingRay]

Originally Posted by Don_Adan

No comments in my resources.
PM sent.

I guessed that which is why I put the comments thing in brackets. But comments could be added so that there's a nice'n'readable disassembled ROM source one day.

[_mandark_]

Originally Posted by Cosmos

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

Works fine on my A1200/ACA1230-28 so far. The only unusual thing I noticed until now is, that it reports as "dos.library V40.-1" when I use the 'version' command.

[cosmicfrog]

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

[matthey]

Originally Posted by StingRay

I disagree totally. ReSource is not the best because it has so many options, it's the best because it has a GUI which makes it very easy to change data types/code etc. pp. Which in turn means that you can get a valid output much faster than with a shell only disassembler. And it's easier to use too.

It's the GUI that effectively allows many more combinations of options. The GUI is both the strength and weakness of Resource. I don't find it easy to use. The command line disassemblers, like ADis and IRA, can create output that is correct enough that it doesn't need changes. The newer version of ADis can disassemble code that will reassemble correctly 75% or so of the time (using vasm) without changes. It would do better but there are many different variations of Amiga hunk files and it needs more work to understand them all. It's instruction accuracy is very good though. It does recognize the data type used to access data and marks it appropriately (e.g. data accessed by a muls.l gets marked signed long and display as dc.l signed_data). It would be possible to mark data as a certain type. I was looking at adding a command line option to do so. A GUI/editor would be nice but a lot more work. The source code is included and pretty understandable for C.

Originally Posted by StingRay

Not true. If you hardcore optimize for 68030 f.e. the code will run much slower on 68060.

Really? I would think a 68060@50MHz would outrun a 68030@50MHz in almost every case with 68030 optimized code. The 68060 should come close to executing an instruction per cycle while the 68030 can't touch that. Throw in many free branches and the branch cache and I don't see it happening, honestly. You could deliberately cherry pick some 68030 optimized code that uses a lot of trapped integer mul or div with 64 bit results or do some funky self modifying code that the 68060 doesn't like but get real. The 68060 outclasses the 68030 but still handles 020/030 code nicely.

Originally Posted by Don_Adan

Yes, moveq #$69,D1 and add.l D0,D0 can be done in one cycle for 68060, but moveq #$69,D0 and add.l D0,D0 can't be done in one cycle for 68060, if I remember right. For this example perhaps is not differences between add.l D0,D0 and add.w D0,D0, but I'm not 68060 expert.

Read page 10-9 of the 68060 User's manual very carefully. It's not very clear but look at the example...

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

[Cosmos]

Originally Posted by Don_Adan

Better use "even" or "cnop 0,2" than "cnop 0,4", due you often lost 2 bytes of ROM space.

even or cnop 0,2 will make address word-aligned : cycles penality on 68000/010 if long read ?

A silly question : functions (declared in the jmptable) must be long-aligned (I don't want any cycles lost on 000/010) ??