New improved intuition.library version from the Kickstart 3.1

[Cosmos]

Question - whatever happened with that updated graphics.library you were working on a year or two back?  I seem to recall it had a lot of promise then just disappeared?  Hope I haven't already asked you this question, memory's a big rusty these days!  

Still working on it from time to time... I have a very very low life condition, so it's a bit hard for me to get my mind concentrate for coding well...


No new version of the intuition yesterday : I was working on a new hack CyberStorm MK2 running now at 105 Mhz...

Pictures on my Warp3D blog this day...

[Cosmos]

Sorry, but that's an issue with your intuition hack. I checked now the source code.  

The corresponding code segment of BenchTrash computes a word-based offset and passes this offset in the form of two 16-bit integers into intuition, namely into DrawImage(). Please check the autodocs, the function takes two *WORDS* and not two *LONGS*, which is a different thing. Only the lowest 16 bits of the arguments are assumed to be valid.  

 Before you're saying that the C "integer promition rule to int" should apply, I suggest that you should familiarize yourself with the calling conventions and the freedoms a C compiler has. An "int" can be both 16 bit (Aztec) or 32 bit (SAS) wide (or, as a matter of fact, even wider if the compiler deems this necessary, though no Amiga compiler picks this choice), thus any type of promition that may or may not take place is the matter of the configuration of the compiler and not in the freedom of the intuition to assume that promotion to 32-bit LONG (and not int) has been performed.  

 I followed a bit the intuition internals, so this problem is not entirely your fault.  

Interestingly, the internal intuition function declares the prototype for DrawImage taking int arguments (!) not WORD (!) arguments, so the problem stems apparently from the fact that the original authors of intuition did not match the external prototype strictly to the internal function, and it seems that the final fix for intuition was only made in an inofficial and non-published version of intuition that was fixed for SAS/C instead of the Greenhill compiler. This version never made it to the 68K's, though. In both versions, however, DrawImage() runs into DrawImageState() which again packs the offsets as two 16-bit entities into a message (intuition aka boopsi aka smalltalk-message, not exec message) and sends this to the corresponding image object (aka, calls its dispatcher). Thus, it remains 16 bit at this point as initially declared, so whether promotion takes place or not is utterly irrelevant *for the original intuition*, despite the fact that the internal prototype does not fit.  If that creates any trouble with your modifications, I suggest that you review your code.  

In one way or another, please remove now the hack of a program you do not own from your pages. At least for my program. Even though I strongly disagree with hacking up intuition like this, especially as it creates problems you have experienced, I'm at least not its owner, so I cannot really complain as the intuition author. I can claim as the BenchTrash author, and that's what I'm doing here. Fix the source at its origin and match your code to the official prototype.

What ??

The bug is from the bsr.w JL_3_1A42 & beq.w JL_3_1A24 !

Since no tst after the bsr, the beq take the CCR from the jsr -$72(a6) savestackmove who is wrong... I have removed these useless savestackmove, so your BenchTrash bug now...

You have to add a CCR Z by yourself (moveq #1,d0 is perfect) at the end of JL_3_1A42 after the jsr -$72(a6) because R_DrawImage return none : it's a bug from you...

No shame to code bug, I code bug too and all coders bug sometimes...


@Thomas Richter

I'm in a rage you cannot imagine : I think you are a satanist who want to destroy my works, my dreams and my reputation...

For this type of issue, private message is available but you want to f**k me in public here...

I really don't like that... Be carefull with me, I can be very very bad...

[Cosmos]

intuition.library v40.86 beta 6

  - R_OpenWindowTagList now SMART_REFRESH mode
  - R_GetDefaultPubScreen optimized
  - a lot of tiny subroutines inlined
  - 9256 bytes saved


==> http://leblogdecosmos.blogspot.fr/p/coding.html

[Cosmos]

Silly guy as always : the law is a lie to rob the people "legally" : so, I do what I want...

You (and everyone else) can put your rights in your a** very deeply...

[Cosmos]

I need to explain somethings :

1/ after disassembling, the Kickstart 3.1 is really slow for me
2/ the intuition.library is certainly the slowest
3/ i'm perfectionnist and cannot live using a slow Kickstart on my Classics
4/ i know asm coding but no C/C++
5/ near all coders contacted many years ago refuse to improve somethings on 68k
6/ or give sources to me (except one personn)
7/ so I lost many precious years to learn reverse engeenering
8/ PPC is a complete dead-end, created since the beginning by the ennemies of the Amiga Classics
9/ for of course Atari and Commodore goodbye
10/ with PPC, many Amiga coders loose times & energy for nothing (= no success, only about 5000 AmigaNG users actually versus 5 millions Amiga68k users in the past) : superb trap...
11/ one of my idea is to do what the Amiga's ennemies don't want we do : keep going the 68k evolution...
12/ all my work is hack yes, but not dirty : all my sources and improvements are very clean & clear...

If you are unable to understand theses evidences, it's YOUR problem...


I gave an example at the end of the intuition.readme : on a 68000/010, my code is more than 200 times faster...

(Ok, I wrote "RJ Mical" : was a stupid french joke, all apologies, I'll remove this name. It's a compilator problem, not a coder problem...)


Another example who make coders cry : R_DrawImage

R_DrawImage
   move.l   d1,-(sp)         
   move.l   d0,-(sp)
   move.l   a1,-(sp)
   move.l   a0,-(sp)
   jsr      _DrawImage
   lea   $10(sp),sp
   rts

_DrawImage
   move.l   d2,-(sp)
   move.l   8(sp),d0
   move.l   $C(sp),d1
   move.l   $10(sp),d2
   clr.l   -(sp)
   clr.l   -(sp)
   move.l   $1C(sp),-(sp)
   move.l   d2,-(sp)
   move.l   d1,-(sp)
   move.l   d0,-(sp)
   bsr.w   _DrawImageState
   lea   $18(sp),sp
   move.l   (sp)+,d2     ; make the wrong CCR for BenchTrash 1.73
   rts



Now it's of course :

R_DrawImage
   clr.l   -(sp)
   clr.l   -(sp)
   move.l   d1,-(sp)
   move.l   d0,-(sp)
   move.l   a1,-(sp)
   move.l   a0,-(sp)
   bsr.w   _DrawImageState
   lea   $18(sp),sp
   rts

who is now more than 3 times faster on a 68060...

[Cosmos]

@Matthey

You and ALL Classics users are agree with me when I want to make an important library romable. Users want simplicity : if Phase5 with the BlizzardPPC and MK3/CSPPC have included
CyberGraphX4, BVision & CyberVisionPPC monitors and Warp3D into their firmware, they have sold many many many more hardware for sure...

It's like Elbox with their FastATA driver & pci.library & Picasso96 software : they will sold thousand Mediators & FastATA if drivers in rom...

Users are bored with complicated software installations, you know that like me... They left Amiga Classics because it's becomed too much complicated...

When I ask for this very small feature (making romable take maximum 1 hour of coding), it was always no or no answer...

When I asked two times Amiga Inc. for a new physical Kickstart 3.9 : no answer...

So what ? You want me cool after that ? No, I cannot stay cool, sorry...


@Joloo

This beta 6 is a WIP : still a lot of work to do to get it really fast, please understand...

And the example in my intuition.readme is not glued-code...


@Duce

Do what you want, I don't care...

[Cosmos]

Excuse me, this is very little code to judge the compiler by. You're looking at one toenail of the left forepaw of the elephant, so to speak.

Intuition was built with the same 'C' compiler which was used for building the entire original Amiga operating system (Green Hills 'C'). That 'C' compiler was truly excellent, and just to put this into perspective, it took the Lattice/SAS 'C' compiler almost ten years to catch up to it in terms of code quality.

The one big difference between Green Hills 'C', and the Amiga-native Lattice and SAS/C compilers is in how parameters are passed to functions. Lattice and SAS/C could pass function parameters in registers (a0/a1/d0/d1, other registers could be specified as needed), whereas Green Hills 'C' exclusively passed parameters on the stack.

Passing parameters on the stack was not an indication of poor code generation, it was merely how the ABI of the operating system target platform wanted it to be done: Green Hills 'C' was a *Unix* targeted optimizing compiler (back then the focus was on portable 'C' compilers and optimizing 'C' compilers were rare), for the Sun 2 and Sun 3 workstations, which was cleverly reworked into a cross-compiler for the Amiga.

If you want to critique the quality of the Intuition code, please cast your eye on the meat, bones and nervous system of the beast.

All my intuition.library source is full of examples I gave... This library is the slowest of the Kickstart 3.1 for me...

I'll show you another example for the beta 7 release if you want...

Note : passing args with registers is more 4 or 5 times faster than by the stack, specially on 000/010/020 who don't have datacache... And we don't need the addq/lea after the subroutine...

And making thousand supertinysubroutines (3 or 4 mnemonics) called by bsr/jsr is not a sign of a good compilator... Inlining is MUCH faster, really...

[Cosmos]

New beta 7 maybe this day...

I removed all 68000/010 support : take a lot of cycles for nothing for me...

There is a big difference between 000/010 and 020+ : I cannot lay good code anymore with all the 000/010 limitations...

[Cosmos]

Romable = firmwareable = Denebable = epromable = eepromable...

===> http://warpclassic68k.blogspot.fr/2013/01/romability-eng.html (in english)

[Cosmos]

The DrawImage() stub in intuition.library calls the local DrawImageState() function and bypasses the LVO, which means that if you should patch DrawImageState() through SetFunction(), then DrawImage() will not invoke the patched function. I'd call this a bug in intuition.library V40

There is a lot of "direct" calls with bsr in the intuition.library (R_RemakeDisplay and R_RethinkDisplay for example) and in many other libraries in the Kick 3.1...

Why not optimize CopyMem() ?

Look at this readme and check benchmarks. Using so called "optimized" CopyMemQuick() only pays off when you are copying small buffers (16 bytes or less) but then if you want really good performance for such small copies it is better inline it.

Done since a long time directly in the 68060.library... And better code from Matthey a bit optimized by me (faster lsr instead of btst and only one move16 in the loop...)

[Cosmos]

Note : I use the word "optimize" but it's not the correct one !

I should use "make simpler" : compilator make (very) complex code, and I just simplify... And it's faster...

After that, most of the time a LOT of "optimizations" must be made for a visible speedup by the users...

It's a very long run...

[Cosmos]

Upload in few minutes !

 intuition.library v40.86 beta 7 68020+ (101 024 bytes)

  - R_AddClass optimized
  - R_FindClass optimized
  - R_FreeClass optimized
  - R_ObtainGirPort optimized
  - R_ReleaseGirPort optimized
  - R_RethinkDisplay optimized
  - R_RemakeDisplay optimized
  - R_RemoveClass optimized
  - some subroutines called one time inlined
  - a lot of absolute addresses turned relative
  - removed all 68000/010 support
  - 13 512 bytes saved

==> http://leblogdecosmos.blogspot.fr/p/coding.html

[Cosmos]

Wawa explained it very good. People (both users and developers) on 68k have to decide what they want, hack around with the old codebase, adding patches that do not really make it better or supporting a new clean platform that makes it easy to integrate patches in the OS (something that already has happened). Of course progress does not happen if people only sit there twiddling thumbs and moan about the situation. If people want future the choice is clear.

No : we need only one direction, and all together... And the RIGHT direction (success), not the many dead-ends...

But it's impossible for many reasons (money, old fight PUP/WOS, big melon...)