new ixemul V62.1 for 68k.

[Piru]

Here is ixemul for 68k.

I was going to write a rant how wrong most of those changes are. Then I realized you will not listen anyway, and deleted the post.

Ixemul is a lost cause.

[Piru]

Man, you're making so tons of wild baseless accusations these days, as well as keeping up with your unbelievable level of incompetence and ignorance.

static lib and blow up program size if you increase it larger.

Wrong.

You can use all Amiga Funtions with ixemul too

Regardless how much you keep repeating this it won't become true. There is no easy way to use amigaos calls in ixemul safely.

Seriously you're claiming to be a developer and not know basic things such as these? Maybe you should have kept to basic.

[Piru]

This sentence is correct 68k libnix is a static lib.when i enhance this, then program size grow.

If you don't even understand how link libraries work I don't think it's worth trying to explain it to you now is it?

when MOS need not link static and increase the program size, how is the library name then ?

Excuse me?

Also the ffmpeg release fab do seem a static build, because when i search for text .library in the exe file i find only bsdsocket.library opening, intuition.library opening.

Of course it is static. Fab told you it is static libnix build. Why wouldn't it be?

Regardless how much you keep repeating this it won't become true. There is no easy way to use amigaos calls in ixemul safely.

and wy not ?

Well let me name some:
- the ixemul signal handling aborting an OS call in the middle of execution, possibly while holding a critical system semaphore
- total leakage of any AmigaOS allocated resources on exit() or abort() (and yes, libnix does have the same problem, naturally... the point is that you cannot mix some random nix code with amigaos code unless if you're very very careful)

The newflash is: There is absolutely nothing you can do inside ixemul to "fix" these issues. This is because ixemul never was supposed to be mixed with AmigaOS calls, it was designed this way.

I've told you this before. You ignored me.

I am sure you will find some lame excuses to ignore me again, and perhaps add some new magic flag or env-variable to fix some totally unrelated thing, and then call the probem solved.

You should have renamed your experimental "ixemul". Now it's too late.

[Piru]

Qed

[Piru]

I can say you, that i planed buy a Mac mini and maybe MOS.But now i am sure, i not buy or need it, because guys that do that, the feature we not have we need not, i dont want suppport with money.

Excellent news!

[Piru]

did i miss some information ?

Yes, you miss a lot of information.

if MOS release libnix source

libnix is not open source.

BTW the limitations of the 68k libnix are mostly not present in the MorphOS version. We're not blind, obviously we have taken care of such issues. Funnily enough, under MorphOS the 68k apps built with 68k libnix have much faster memory allocation than ixemul ones.

[Piru]

where can see what API functions the libnix of MOS have ?

man ar then apply this knowledge.

void *malloc(unsigned long size)
{
  struct MinNode *node=__memorylist.mlh_Head;
  struct MemHeader *b;
  ULONG size2,*a;

  size+=sizeof(ULONG);
  while(node->mln_Succ) /* yet some memory in my list ? */
  {
    if((a=Allocate((struct MemHeader *)node,size))!=NULL)
    {
      *a++=size;
      return a;
    }
    node=node->mln_Succ;
  }
  size2=sizeof(struct MemHeader)+sizeof(ULONG)+size; /* Total memory needed */
  if(size2<=_MSTEP)
    size2=_MSTEP; /* Allocate a _MSTEP bytes large block if possible */
  size2=(size2+4095)&~4095; /* Blow up to full MMU Page */
  if((b=(struct MemHeader *)AllocMem(size2,MEMF_ANY))!=NULL)
  {
    b->mh_Lower=b->mh_First=(struct MemChunk *)(b+1);
    b->mh_First->mc_Next=NULL;
    b->mh_Free=b->mh_First->mc_Bytes=size2-sizeof(struct MemHeader);
    b->mh_Upper=(char *)b+size2;
    AddHead((struct List *)&__memorylist,&b->mh_Node);
    a=Allocate(b,size); /* It has to work this time */
    *a++=size;
    return a;
  }
  return NULL;
}

Oh yes, forgot how braindamaged the 68k libnix was. That indeed can get really slow, even under MorphOS. Well, at least there's no such problem with MorphOS native libnix.

Which reminds me: AmigaOS 3.x memory pools have the same problem. AmigaOS 3.9 tried to fix it with AVL trees, but the whole concept is still flawed (read: based on slow first fit algorithm both for internal and external allocations).

Even the AmigaOS 3.x with TLSFMem patch fails to fix it properly: It only changes the behaviour of the external allocations. Internally the pools still use either list or tree and Allocate/Deallocate for the internal allocations.

This means that anything using memory pools in AmigaOS 3.x will inherit the performance problems aswell.

MorphOS 2.x and later took a different approach. There all memory pool allocations and deallocations are O(1).

[Piru]

@piru:

after you mention it i made tests with two quickie opengl ports i did for 68k. i compile them usually with -noixemul > libnix but now i linked against bernds ixemul too. i using wazp3d fps counter that shows me a ms count per frame if it wents under 1 fps i cannot trace any speed difference between both libraries, but then i suspect there is not much memory allocations they do.

You suspect correctly.

maybe i should try to run netsurf port on chris hodges tlsf. could it make any difference?

In practice, no.

There are several levels for the allocators, typically at least two. In amigoid systems there typically are at least 3:

OS low level: AllocMem/FreeMem (etc)
OS high level (pools): AllocPooled/FreePooled
libc level: malloc/free

For example platon42's TLSF patch only affect the OS low level. Depending on how the higher level allocators are implemented, modifying the lower level allocator might have some effect or practically none at all. For example TLSFMem has very little to no effect on AmigaOS 3.x AllocPooled/FreePooled performance. Additionally 68k libnix allocator will be slow regardless of TLSFMem.

The reason is that both memory pools and the libnix malloc actually maintain their own memory lists, which are relatively slow (due to poor choice of "first fit" algorithm). These allocators rarely call the lower level allocator.

Luckily the allocator speed is rarely an issue. It might be with some C++ apps for example, or with some complex applications such as IBrowse. With IBrowse you can easily spot the slow down after couple of days uptime.