AmigaOS 3.2 performance vs 3.1

[Don_Adan]

Originally Posted by Thomas Richter

Consider programs showing disk content. For large files, they will just show the wrong number. Consider a copy program that allocates buffers or space on the target according to the size in the file info block. We cannot fix them, but we can avoid that major havoc happens if you use such programs. For example, by not showing them in the directory unless the right function is called, or by creating an error if you attempt to get information on them with the wrong functions.


A little bit more care is needed.

If someone will be try to do this, then he can't.
Similar like copy files with long file names (from SFS or PFS) to OFS or FFS diskette is impossible without file renaming.
You want to protect Amiga users against make stupid things.
This is bad way.

Progress? Amiga? Let's be real, please. This is really a historic system, and not a productive environment. There is not really a use case for such large files. Will you view DVDs on the Amiga? No. Burn them? No.

Yes, progress. I think that PiStorm has enough power to view/burn DVD on Amiga.
Previously Amiga limitation was too slow CPU.
Now limitations are old Amiga kickstarts standards like 2 GB file length limit and 2GB memory limit.

[patrik]

Originally Posted by SpeedGeek

It seems that P5 had worked around the CVision3D Board issue with their 030 CGX driver. I didn't find anything in the CVision3D manual requiring anything but the 030 CGX driver.

Originally Posted by Thomas Richter

From the manuals I have, it says that you are supposed to run "Enforcer QUIET".

From reading the CGX V3 FAQ, it they claim Enforcer is only needed in Zorro2 mode with 68030:

Q: Why does the CV3D install disk say that I need to run enforcer
   if I have a Amiga 2000 with a 030 card?
A: Enforcer is needed for all machines that have a 030 and run 
   the CV3D in Z2 space. The problem is that the io register space 
   is in Z2 space with a2000 and Z2 space is always cachable if no 
   enforcer is running, since this space also intended for memory cards.
   The CV3D io register space interferes with that caching stuff.
   This is not a problem for a3000 and Z3. Also the 040 and 060 always 
   installs a mmu table at setpatch point (68040.library does that) 
   - the cache is invalidated for z2 space and CV3D works fine.
   This is what enforcer does for the 030.

From http://elwoodb.free.fr/Amiga/FAQs/v3faq.html

[SpeedGeek]

Originally Posted by Thomas Richter

68030UM, page 9-34. Read it. Please. There is no advantage in early termination - in terms of memory, yes. In terms of speed, no.

Ok, I get what you mean. But there is an advantage, in terms of speed (not related to the ATC) because of faster table searches for early termination of page descriptors (which also means termination of 2nd, 3rd or 4th level MMU tables).

There is a way to reduce the number of possible ATC entries with the 1st level MMU table by limiting the number of bits used, which determine the size of the address space managed by the MMU. Hence, effectively allowing early termination of the MMU tables, which will affect the ATC performance.

[SpeedGeek]

Originally Posted by patrik

From reading the CGX V3 FAQ, it they claim Enforcer is only needed in Zorro2 mode with 68030:

Q: Why does the CV3D install disk say that I need to run enforcer
   if I have a Amiga 2000 with a 030 card?
A: Enforcer is needed for all machines that have a 030 and run 
   the CV3D in Z2 space. The problem is that the io register space 
   is in Z2 space with a2000 and Z2 space is always cachable if no 
   enforcer is running, since this space also intended for memory cards.
   The CV3D io register space interferes with that caching stuff.
   This is not a problem for a3000 and Z3. Also the 040 and 060 always 
   installs a mmu table at setpatch point (68040.library does that) 
   - the cache is invalidated for z2 space and CV3D works fine.
   This is what enforcer does for the 030.

From http://elwoodb.free.fr/Amiga/FAQs/v3faq.html

Thank you for the info!

But this really makes no sense because the Z2 I/O space is non-cachable. The real problem with the 030 is that long word aligned longword writes ignore the CIIN signal.

The same problem should affect either Z2 I/O space or Z3 I/O cards. This problem can be worked around in hardware or software, but developers didn't always do that, so Enforcer was the quick fix back then.

Is it possible that the real problem in Z2 mode is the CV643D mapping 4MB of graphics RAM into the Z2 Fast memory space? Note: Normally, this is not a problem for an output only device.

[Thomas Richter]

Originally Posted by SpeedGeek

But this really makes no sense because the Z2 I/O space is non-cachable.

The CV3D has, even in ZII-mode, its PCI registers mapped in the memory space at the end of the video RAM.


Which, in effect, does not make any difference because...

Originally Posted by SpeedGeek

The real problem with the 030 is that long word aligned longword writes ignore the CIIN signal.

...of this. The affected register is the "blitter" status, a 32-bit register aligned to a 32-bit boundary. Thus, P5 apparently received a defect report from a user, found that enforcer fixed it, and added it to the FAQ without really understanding the cause of the problem.

Originally Posted by SpeedGeek

The same problem should affect either Z2 I/O space or Z3 I/O cards. This problem can be worked around in hardware or software, but developers didn't always do that, so Enforcer was the quick fix back then.

Exactly, and thus, this problem was probably not enountered at the time the manual was written.

Originally Posted by SpeedGeek

Is it possible that the real problem in Z2 mode is the CV643D mapping 4MB of graphics RAM into the Z2 Fast memory space? Note: Normally, this is not a problem for output only device.

There is no "memory space" - there are only "large regions" that are allocated in 2MB chunks, or small regions that are allocated in 64K chunks, and the large chunks end up in the "memory region" and the small chunks end up in the I/O space. What board hardware probably does is to map only the I/O space as cache-inhibited, but that does not make any practical difference for the problem at hand because the CIIN-defect of the 68030 is present regardless of CIIN (well, that is the defect).


What the mmulib and the enforcer do is to only map those regions as cachable that appear in the memory list, and thus not the CV3D video RAM and the video registers.


Side information: The GVP EGS 110 has no blitter, and thus can enable caching for video RAM. Thus, GVP added a "startup tweak" to be run before setpatch which added "dummy" memory regions into the exec memory list.

[patrik]

Originally Posted by Thomas Richter

...of this. The affected register is the "blitter" status, a 32-bit register aligned to a 32-bit boundary. Thus, P5 apparently received a defect report from a user, found that enforcer fixed it, and added it to the FAQ without really understanding the cause of the problem.

There are no mirror(s) of the registers in Zorro3 mode given its large 256MB autoconfig size?

[Thomas Richter]

Originally Posted by patrik

There are no mirror(s) of the registers in Zorro3 mode given its large 256MB autoconfig size?

Not that I know of. The register mapping of the CV3D is rather unorthogonal and depends on whether the card is operating in Z2 or Z3 space (or even in PCI space), but the blitter(accelerator) control register is both read and write at the same memory space.

[SpeedGeek]

Originally Posted by Thomas Richter

There is no "memory space" - there are only "large regions" that are allocated in 2MB chunks, or small regions that are allocated in 64K chunks, and the large chunks end up in the "memory region" and the small chunks end up in the I/O space. What board hardware probably does is to map only the I/O space as cache-inhibited, but that does not make any practical difference for the problem at hand because the CIIN-defect of the 68030 is present regardless of CIIN (well, that is the defect).

Side information: The GVP EGS 110 has no blitter, and thus can enable caching for video RAM. Thus, GVP added a "startup tweak" to be run before setpatch which added "dummy" memory regions into the exec memory list.

Whether you prefer to call it a region or an address space really makes no difference. What is important to remember, is that for Zorro2 there are designated cachable and non-cachable address spaces. Zorro2 Fast memory expansions use the cachable address space and Zorro2 I/O expansions use the non-cachable address space.

For Zorro3 expansions, the are no designated cachable and non-cachable address spaces, each board or device determines it's cachable functionality.

BTW, I have a Picasso II+ which maps 2MB of graphics RAM into the Zorro2 cachable space. I would expect that, the blitter register is mapped into the Zorro2 non-cachable space. So, I don't know why P5 would do such sloppy design work when they had a proven good design example available in Germany.

[Olaf Barthel]

Originally Posted by Don_Adan

Which old software You want to fix? And for what?
Same bug/limitation was for HD partition sizes, it was defined as LONG not ULONG.
Then for older kicks You can see negative values as partition sizes.
For all partitions greater than 2GB.
Someone fixed old software which shows wrong partition sizes?
No. Except new programs or new program versions.
Same will be for 2GB limit for file sizes.
Newest programs can handle (show) file sizes as ULONG, even if this is buggy declared as LONG in dos.h.
This is called progress.

There is progress and there is learning to walk on broken glass and not minding the injuries, the loss of blood, the danger of infection and the pain...

Data structures succeed in shaping code more than code in turn manages to shape data structures. We are stuck with operating system components, on multiple levels, which were designed to use signed 32-bit integers to represent anything between quantities, positions and distances.

While the constraints imposed by having to use signed numbers are not beyond fixing and even clever workarounds, it is ugly business even trying to make progress.

New fixes for old code will not translate into more robust or predictable behaviour unless that old code is rebuilt from the source code, or maybe patched in the right places. Such fixes, for example if file size reporting is concerned, will have to work in context with the code that builds upon them. For example, the runtime library that ships with your 'C' compiler will expect signed integers for size and position information and glitch into undefined behaviour without even trying. You could fix that, but you would have to go over the runtime library source code (if you have it) with a microscope and somebody to assist you in verifying that the changes are sound. Sounds like work to me (avoid it if you can). There is the potential that such fixes and workarounds will get you somewhere, and you better consider how much this effort will be worth it to you.

Retroactively changing data structures and APIs is unlikely to yield improvements because software just does not expect such changes to be possible. Furthermore, software and even operating system code, as a rule, practically never ever checks if the parameters for an arithmetic operation to perform are in the expected range, or if the operation results in an arithmetic overflow. Mostly, such code assumes that the parameter values will be in range because, for example, a storage device will never be so large that its size cannot be reliably represented by a signed 32-bit integer (largest disk size for a 1986 era Amiga was 26 * 512 * 8 blocks, i.e. 106,496 * 512 = 54 MBytes). Indeed, the Amiga operating system was not designed to be stable or resilient. There was just not enough RAM or ROM space available to make it so. Also, the burden to restart the system after even the nastiest avoidable crash was rather low (if you could stand the sound of the disk likely getting sawed in half by the Disk-Validator while the boot process was still in progress).

The "prime example" for that is the RAM handler which is expected to run out of available memory long before unchecked integer arithmetic overflows will start to bite. This was a reasonable assumption in 1986 and still is, but long before signed/unsigned 32-bit integer arithmetic trouble enters from stage left, you are already deep into undefined behaviour because RAM handler will have stopped making sense of its own bookkeeping information. This is the "default mode" for the Amiga default ROM file system, too, and reliably unreliable tools such as HDToolbox.

Up until fairly recently, HDToolbox did not know its own limitations and just went over the rails instead, corrupting your hard disk partition information like it was supposed to do that. The same can still be said about the Amiga default ROM file system. Same goes for the scsi.device and the trackdisk.device. Turns out you can ship an operating system if you just stop checking for so many error conditions, freeing up enough ROM space for everything to fit into it. This puts the burden on the developer to be extra cautious and make no mistakes whatsoever when writing the code, avoiding the conditions under which undefined behaviour will invariably result. Guess who knew that these rules applied or managed to apply them

So, what can you do? Make the software and the ROM code more resilient, have it validate the parameters it receives before blindly committing to them and making a mess. That is doable, but will invariably eat either RAM or ROM space like popcorn. Add new APIs and data structures which complement and extend the existing ones, avoiding the ambiguity that comes with signed/unsigned integer operations. This is what was done in the AmigaOS4 dos.library, which has replacements for the signed 32-bit-integer-constrained Examine/ExNext/ExAll functions, etc.

Invariably, you will have to go through the entire operating system and its tools & shell commands, cleaning them up. That takes the kind of grit and courage which is easily mistakable for stupidity

[Thomas Richter]

Originally Posted by SpeedGeek

Whether you prefer to call it a region or an address space really makes no difference. What is important to remember, is that for Zorro2 there are designated cachable and non-cachable address spaces. Zorro2 Fast memory expansions use the cachable address space and Zorro2 I/O expansions use the non-cachable address space.

Well, there are regions some board designers considered to be cachable - that is more appropriate. The trouble is that even the large 2MB areas are not cachable if they represent video RAM of a card that has a blitter. Misconfiguration of caching has, however, only a very limited impact on the 68030 as its cache is really minimal, and you don't read from video RAM that often.

Originally Posted by SpeedGeek

BTW, I have a Picasso II+ which maps 2MB of graphics RAM into the Zorro2 cachable space.

...and its VGA I/O ports into the non-cachable space, yes. That was rather the regular design board designers took. Not so for the CV3D, but it also has many more registers than the GD542x on the P-II, including those of the 3D engine, and the legacy VGA ports that also need to go somewhere.

Originally Posted by SpeedGeek

I would expect that, the blitter register is mapped into the Zorro2 non-cachable space. So, I don't know why P5 would do such sloppy design work when they had a proven good design example available in Germany.

Not sure whether this is supposed to be ironic. P5 is not exactly known for following "design guidelines".