Physically, this is one type of memory which hosts data (DDR2).
It would be useful to request it directly. A new flag could be created (just for example: MEM_DDR).

Roughly, the idea is:
A single memory allocation request with this new flag
Loading a structured data file.
Pointers to use its data (images, animations, sounds, text, etc.).
It seems cheaper for writing a code.

The pictures (and sounds) in the database would probably be compressed as most picture formats today. The decompression can happen from MEMF_ANY to MEMF_CHIP by the CPU with good speed avoiding a separate memory copy. The database could keep filenames of the pictures (and sounds) and simply pass the filename to datatypes.library which should minimize any copying if it's smart. 

Marcel Verdaasdonk wrote:

SID i can tell you that without a doubt the Harvard architecture is more secure then a Von Neumann.   So can you explain to me why two memory requests are bad?   Data should be in chip instructions in fast.

Are you trying to confuse SID? The only useful aspect of a Harvard Architecture that applies to the Amiga is having separate instruction and data caches. This allows the instructions to be fetched at the same time as data is fetched as requested by instructions. This is faster but doesn't provide any extra security. Maybe you refer to not allowing instructions to use PC relative addressing modes for writing? That's really a joke as it can be defeated with 2 instructions. A MMU/MPU is needed for security.

In the Amiga there are two options either use any memory or chip memory.
The prior being the more safe choice when writing OS friendly software.
To be honest I would simply place the Data in chipmem and the Main in any.(Hey this seems a little like a Harvard CPU design)
A MMU on the other had does not directly imply security.(on the Xbox there are several fine examples where it usually goes wrong in the chain of trust.)

For this facility, the header file EXEC_MEMORY could be extended.

According to Thomas Richter, this is just a matter of how decoding and routing address.

WHY do we need it!!!

 
Example assembly-like language:
  move.l EXECBASE,A6
  move.l x,D0
  move.l chip,D1
  jsr EXEC_ALLOCATEMEM(A6)
  move.l D0,ptr-mem-chip
 
  move.l EXECBASE,A6
  move.l y,D0
  move.l fast,D1
  jsr EXEC_ALLOCATEMEM(A6)
  move.l D0,ptr-mem-fast
 
 
The same example but in C-like language:
 
  ptr-mem-chip=AllocMem(x,chip)
  ptr-mem-fast=AllocMem(y,fast)
 

And now, what is requested:
  ddr2-size = z
  ddr2 = MEMF_DDR2
 
  move.l EXECBASE,A6
  move.l z,D0
  move.l ddr2,D1
  jsr EXEC_ALLOCATEMEM(A6)
  move.l D0,ptr-mem-ddr2
 
or
 
  ptr-mem-ddr2=AllocMem(z,ddr2)

Since your feature request pretty much shows a lot of similarities with MEMF_ANY.
So what sets you requested feature apart?

Sorry, I still don't get it. It sounds for me as if you believe that allocating memory is a heavy-weight operation. It isn't. The overall time of a codec is spend in the actual coding or decoding, and not in memory allocation. It really doesn't matter, and there is nothing to worry about.

That AmigaOs reacts more critical on memory allocation changes is rather a by-product of not providing automatic stack extension. Under Linux, stack and heap are mirrored into the overall address space of the process, and the stack is extended automatically whenever needed, so grows linearly. AmigaOs doesn't have that (lacking a MMU), and thus programs usually allocate memory for all types of temporary object you would otherwise simply put on the stack. The latter method is usually faster and simpler, but not available with the rather draconic 4K of stack you get by default. Besides, if that stack overflows - regardless of whether you extended it yourself or not - the program just crashes. Not a good option if you ask me.

There are other considerations besides simple (generally simple=easy for humans). You may only see the problem from that of a programmer (software view). I see 3 considerations:

1) Simple or easy to use from programmers perspective
2) Simple or easy to create from hardware perspective
3) Speed and performance

I think 1 supports a unified memory while 2 and 3 likely support a divided memory.

There are good reasons not to have a separate memory model as the Amiga has, but easyness of the interface or performance of the memory allocation is not one of them.

SID Hervé wrote:

The chipset retrieves directly raw data previously decompressed by the CPU.

There are good arguments, but this isn't one of them. For the CPU it is for free just to write the data elsewhere. Just to give you an example, JPEGs output DCT stage would just output to a chipmem buffer instead of a regular memory buffer. There is no double copy involved in this case.

The point should rather be (your point) that with a memory interface fast enough, custom chip access cannot block off the CPU in first place, so it doesn't make sense to have a distinct chip memory anyhow. So in a sense, I do not see why we have MEMF_CHIP there as I don't quite see why it makes things simpler. It only makes things complicated, and it is an anachronism which is based on design decisions taken 20 years ago that are no longer valid.

ThoR is correct but he forgot to mention somethings, but that is besides this point.(it is more likely he didn't felt like bringing system subsystems into the tread.)

Look, a cleverly written JPEG will do the following: Take the source data, which is in its own buffers (AllocMem() in the jpeg library). Transform it into the output buffer provided by the user/client program (AllocMem() of the screen memory). There is no way the jpeg library could or would allocate screen memory in first place. How should it know where the program wants it? Typically, even other things happen: The data first goes to an output memory provided by the user program not even on-screen, and is then blitted and clipped into the output window, thus there are then three buffers involved. And even more: If the image is color-transformed, the DCT transformation will also first go into a buffer, and an additional color transformation and interpolation step will transform the DCT output buffer into the JPEG output buffer, so four buffers then.

IOW, AllocMem() is completely irrelevant as an operation, and the data is copied over and transformed more than once. File system buffer -> huffman buffer (1) -> huffman to DCT intput buffer (2) -> Dequatization DCT input to DCT output buffer (3 - typically different) -> (4) DCT output buffer to color transformation output buffer (5) -> color transformation output = client program input buffer to screen memory (6).

So the data is more or less touched six times, in a sense. Some of the buffers could be co-located, depending on the coding options, but usually they can't.
 

SID Hervé wrote:

It seems to me it's a better or an another way of expressing the problem.

I'm sorry, but the two seem to be rather unrelated.

Is this what you are talking about:

MEMF_CHIP = "I want RAM where the custom chips have priority over the CPU"
MEMF_FAST = "I want RAM where the CPU has priority over the custom chips"
MEMF_SID = "I want RAM where first come, first serve"
MEMF_ANY = "Don't care, just give me some RAM"

I don't think that this makes much sense but it seems to me that your question has not come across which is why I am asking.

With regard to the Natami, since all accesses go through the same single hardware bus, there is no obvious reason for a differentiation between chip mem and fast mem but perhaps Thomas has some ideas for the access arbitration where priorities of accesses will be different depending on where the target addresses reside. For example, one might assign some of the DMAs a relatively low priority and provide some internal buffers to compensate for some arbitrary latency. If the CPU accesses virtual fast mem, its access could be preferred over the low-priority DMA but not if the CPU accesses virtual chip mem.

This would be a tribute to the fact that there has been this kind of differentiation in the AmigaOS from the very beginning. Other than that in my opinion it wouldn't be a compelling design decision to tie software to a specific hardware implementation. On the other hand, this is an Amiga where we don't want a million levels of abstraction... :)

Regarding adding yet another type of RAM to allocate, I don't think that even more arbitration complexity should be visible from the perspective of a programmer.