New improved intuition.library version from the Kickstart 3.1

[psxphill]

RJ Mical will eat his hat !!

He left commodore in 1986, before 1.2 was released.
 
So you can only be sure that the code in 1.1 was his, which it might well be. I suspect at the time he was purely interested in getting the damned thing shipped

[psxphill]

They believe they are God : the super Amiga elite, have a very very big melon, have reason on anything, think I'm an idiot and don't want to share anything on their super-hyper piece of coding... Ridiculous !

Your ranting is doing you a disservice.
 
 I personally wouldn't want to run a hacked version of intuition that ignored what type of window the developer wanted, but some of your patches seem ok.
 
 Your attitude puts me off though.

[psxphill]

Cosmos try to fix some libraries and is criticized... people is stupid.

If you can't handle criticism with dignity then you should avoid the internet. He criticises people and expects them to take it, but criticise him and he launches an attack.

I am not a lawyer but some countries reverse engineering laws might make his patches illegal. Not that I care.

http://en.wiktionary.org/wiki/you_can_catch_more_flies_with_honey_than_with_vinegar
 
 

Coders are a bit special, it's like that : me too I'm special... It's just a fact : it's impossible to talk and trade with coders from my experience... They (hum... we) live on an "another planet" ! lol !!

 
 You can overcome your narcissism if you want. You only live on another planet because you chose to.
 

I have some secret goals with them, I cannot explain because Amiga have a lot of and powerfull ennemies...

 
 Paranoia is treatable too.

[psxphill]

Really you are worried about the laws of patch intuition.library? you are ironic about that

I plainly said that I didn't care.

PS: The wikipedia link is crap.

Try reading it again.
 
 

Which countries do you have in mind?

 There are various situations where it's illegal in the US and the EU.
 
http://en.wikipedia.org/wiki/Reverse_engineering#Legality

[psxphill]

But the kind of reverse engineering that is going on here in Amigaland is explicitly legal.

Can you point me to where it is explicitly stated that it's legal?

[psxphill]

Years of x-copy on amiga land and now you are here crying for non sense

 I'm not crying, I'm discussing facts not opinion. I'm not going to ignore facts just because they are inconvenient.
 

enjoy the library and shut up.

I don't do requests.

[psxphill]

No, I am assuming CopyMem() is highly optimized just like CopyMemQuick(). If CopyMemQuick() is using better memory copy routine than its CopyMem() counterpart then there is something seriously wrong.

Why would you assume that? CopyMemQuick() is obviously supposed to be more optimised, because it has the word "Quick" in it.

[psxphill]

Given how cheap Commodore was, the ambition never resulted in such hardware showing up, though.

Commodore poured a load of money into the Amiga before the A1000 launch. They then invested in cost reduction for the A500.
 
 Up until 1987 what they were doing made sense. The problem came in 1988 when AAA was started. It wasn't that they didn't invest any money, what they invested didn't turn into real products.
 
 Finally sense prevailed and AGA was started. While AGA rollout was delayed due to management silliness, the money spent on AAA was wasted with mutually consent.

[psxphill]

Why not optimize CopyMem() ?

It can never be as optimised because CopyMemQuick() only works on long word aligned data, while CopyMem() has to work on arbitrarily aligned data.



The following samples show how to use the copying routines.

APTR source, target;

source = AllocMem(1000, MEMF_CLEAR);
target = AllocMem(1000, MEMF_CHIP);
CopyMem(source, target, 1000);

CopyMem() copies the specified number of bytes from the source data region
to the target data region. The pointers to the regions can be aligned on
arbitrary address boundaries. CopyMem() will attempt to copy the memory
as efficiently as it can according to the alignment of the memory blocks,
and the amount of data that it has to transfer. These functions are
optimized for copying large blocks of memory which can result in
unnecessary overhead if used to transfer very small blocks of memory.

CopyMemQuick(source, target, 1000);

CopyMemQuick() performs an optimized copy of the specified number of bytes
from the source data region to the target data region. The source and
target pointers must be longword aligned and the size (in bytes) must be
divisible by four.

Not All Copies Are Supported.
-----------------------------
Neither CopyMem() nor CopyMemQuick() supports copying between
regions that overlap.

[psxphill]

Only function prologue and epilogue are different. In CopyMem() they are longer, prologue because it must check long word alignment and epilogue because it must check if there are remaining bytes to copy.

You can fall back to CopyMemQuick() in CopyMem() if the data is aligned, but as you say that takes time and you still have to handle the non aligned case.

It should be possible to optimise for small copies too, but identifying the cases for selecting which algorithm has additional overhead. Ideally you should identify the small copy cases first so that the overhead per byte is kept to a minimum. However even calling through the LVO is part of that overhead, so a copy of 4 bytes is never going to be optimal.

[psxphill]

I'm not clear which programs actually use CopyMemQuick() anyhow - probably the FFS does in case the "Mask" does not fit the target of the memory buffer (i.e. the handling device is "broken" and cannot reach the memory indicated as buffer by the caller).

The device isn't broken if it can't reach all memory. Exec was designed around not copying messages, therefore a device is broken if it does a CopyMem() to get the buffer into ZorroII or chip ram.
 
 It actually sounds like a hardware limitation to me.
 
     Mask=<0xffffffff>  Address Mask to specify memory range that DMA transfers can use at one time with any file system. Use Mask for compatibility with older hard drive systems.
 
 You should be able to achieve what you need with
 
     BufMem Type=<3>  Memory type used for buffers; (0 and 1 = Any, 2 and 3 = Chip, 4 and 5 = Fast).
 
 Although I don't know if you can specify 24 bit fast.
 
 It would make more sense when allocating memory to tell Exec what you were planning on doing with it, so it could allocate memory in the correct range and could also provide protection for it. This would go all the way back to the application that would allocate it's buffers saying it would be passing it to a dos stream, which would make sure the device could access it too.

[psxphill]

The problem is: You cannot just open a device, perform a DoIO() or SendIO() and expect this to get the data. Now, where do you get the correct memory from to read data into? Answer is: The caller cannot possibly know that. Hence, "broken by design".

The caller has to know or you'll get terrible performance, hence you provide that when you mount the file system. It's not perfect and should have been handled by asking the devices/libraries/file system what type of memory is acceptable.

By making it not work properly when given incompatible memory it at least forces the developer who is calling the device think about how to solve the problem in the most optimal way (which is likely by allowing the user to specify what type of ram to use as a buffer like the file system does).

[psxphill]

Ok, so let's think this to the very end, will we? If I call a device, I need to know the memory type it is able to handle and allocate that (is there a MEMF flag for every memory type a device needs?

Generally there is.

As for example, Zorro-II memory on *this* GVP board, or 32-bit memory on the CPU-board?). What if the caller needs the data in other memory regions? For example because it is an audio sample? Or a graphic for the graphics board? Or a program to load into 32-bit board memory? Thus, a caller has to create an off-target buffer, load the data in there and then copy it around.

I'm not aware that this is a general problem. i.e. a SCSI controller only has ram on it as a convenience to the user for reducing the number of cards required. If there is an additional card that has ram with the same MEMF flag then that is also acceptable (usually 24 bit dma).

I agree that there are some theoretical issues with MEMF and it is also inconvenient as it requires external knowledge and it would have been better if amiga had been forced into providing a better solution. My argument is that having a central system which coordinated memory allocation between components so they are as optimal as possible and only if that all falls down a fallback that allocates buffers is a much better solution than what you propose.

Or to put it in a different way: There's a reason why every other operating system I know handles it the way I consider the correct way (off-side buffers for devices that cannot DMA into all regions), only AmigaOs doesn't.

AmigaOS is the only one that sends messages without copying them too. I understand your argument, I understand why the other operating systems do it that way. I don't buy that it's the correct way that AmigaOS should work.

The FFS Mask/BufMemType flags are workarounds CBM invented because the trackdisk.device was broken and couldn't work with FFS out of the box. That's really all. Then it became an excuse for lazy device implementations, unfortunately.

No. The Mask for was a supposed broken hard disk. BufMemType was for trackdisk to avoid copies, not because it was broken. devices not implementing side buffers was on purpose, not because of laziness. AFAIK trackdisk allowing fast ram transfers had more to do with mfm decoding being faster when using the cpus available at the time than with the blitter (due to the number of passes involved with the blitter).

I've been in a similar position to you where I've justified each component doing copies on a framework that I built, but it all ended up being memory hungry and slow. On a further redesign I was able to reverse my decision and the difference was visible.

[psxphill]

But we're talking about AmigaOs, and as I already said: At *some* point, the copy has to be made. At file system level, or at device level. The question is just *where*. And the answer is quite obvious: Whoever created the mess must clean up.

Your solution is not obvious if you want the best speed. Forcing everything in the system to take copies is the worst solution for performance and for the sanity of the device developers.

A good solution would allow you to stream data from a file on a hard disk into memory on a sound card without any cpu copying involved ever with the hard disk device and the sound card device negotiating how to do it through an exec api. If copying was required then it would be exec that would do it.

Then again, where do you suppose to make the cut? At File system level? At user program level? If you make it at file system level, there is no freaking difference. Wether the FFS copies the data, or the device copies the data makes no difference.

Why do you need to copy the data? If you're streaming data then buffering it is pointless. If you've told the file system to buffer your file then it makes sense for the file system to take copies, but that should be optional.
 

Unfortunately, that is not true in this generality. For example, there is a batch of A4000 where CBM in their wisdom installed the wrong bus drivers for motherboard RAM (inverting instead of non-inverting). For the CPU, it doesn't make a difference since the data is read and written just "upside down". For DMA, it means that you get all your data inverted from the disk into the RAM. Thus, the only safe destination is really RAM on the card.

I've not heard about this. Any zorro transfer into motherboard ram (chip and fast) is broken? That definitely would require the type of system I'm proposing as it's the motherboard that is broken and making every device avoid dma'ing into motherboard ram is a horrible idea.

[psxphill]

I'm not forcing to make copies. I'm requiring that devices provide the data where the user requested them.

And the user cannot allocate memory in the most optimal way, so you are forcing devices to make copies.
 
 If the user allocates memory then for performance you need to make it the applications responsibility to allocate the correct memory, which is what we have now.
 
 Saying it's broken because it doesn't work like Windows is a rather odd stance.