Welcome, Guest. Please login or register.

Author Topic: new ixemul V62.1 for 68k.  (Read 10561 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline itix

  • Hero Member
  • *****
  • Join Date: Oct 2002
  • Posts: 2380
    • Show only replies by itix
Re: new ixemul V62.1 for 68k.
« Reply #74 from previous page: November 19, 2009, 12:01:16 PM »
Quote
when amiga OS go memory Protection.

For fantasy writings I prefer J.R.R. Tolkien.
My Amigas: A500, Mac Mini and PowerBook
 

Offline wawrzon

Re: new ixemul V62.1 for 68k.
« Reply #75 on: November 19, 2009, 12:33:14 PM »
@itix: maybe you should try "the witcher" of sapkowski - a bestseller from poland. lol. there is also a rpg made aftert that. it is probably more like bernds world. i dont know if its available in finnish though.
 

Offline Piru

  • \' union select name,pwd--
  • Hero Member
  • *****
  • Join Date: Aug 2002
  • Posts: 6946
    • Show only replies by Piru
    • http://www.iki.fi/sintonen/
Re: new ixemul V62.1 for 68k.
« Reply #76 on: November 19, 2009, 12:39:38 PM »
Quote from: bernd_afa;530116
where can see what API functions the libnix of MOS have ?
man ar then apply this knowledge.

Quote
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).
« Last Edit: November 19, 2009, 12:49:27 PM by Piru »
 

Offline wawrzon

Re: new ixemul V62.1 for 68k.
« Reply #77 on: November 19, 2009, 04:27:03 PM »
@piru:
Quote

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.

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.

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

Offline bernd_afaTopic starter

  • Sr. Member
  • ****
  • Join Date: Nov 2005
  • Posts: 479
    • Show only replies by bernd_afa
Re: new ixemul V62.1 for 68k.
« Reply #78 on: November 19, 2009, 04:39:16 PM »
>Well, at least there's no such problem with MorphOS native libnix.

and no problem with ixemul.mem alloc is fast enough for real world C++ programs and netsurf

with that program you can measure it

http://aminet.net/package/dev/misc/LibraryTimer

malloc/free need around 2-3% of overall CPU usage with netsurf.

but with poolmem you get after longer use much more time

>For fantasy writings I prefer J.R.R. Tolkien.

I watch out for news of Hyperion Secret Project on their Webpage.maybe they do memory protection... ;-)

but anyway, a Function that set and get Task user Pointer is the cleanest solution so nobdy need hack in the task structure.

and it make no problem with ixemul.
« Last Edit: November 19, 2009, 05:48:11 PM by bernd_afa »
 

Offline Piru

  • \' union select name,pwd--
  • Hero Member
  • *****
  • Join Date: Aug 2002
  • Posts: 6946
    • Show only replies by Piru
    • http://www.iki.fi/sintonen/
Re: new ixemul V62.1 for 68k.
« Reply #79 on: November 19, 2009, 05:33:55 PM »
Quote from: wawrzon;530310
@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.

Quote
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.
 

Offline bernd_afaTopic starter

  • Sr. Member
  • ****
  • Join Date: Nov 2005
  • Posts: 479
    • Show only replies by bernd_afa
Re: new ixemul V62.1 for 68k.
« Reply #80 on: November 19, 2009, 05:49:52 PM »
>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.

memalloc performance is only important when often mem is alloc and free during program run.you must first find such a program.programs that use xml library (netsurf) or C++ programs are good candidate

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

no this not help also not with libnix programs that use malloc.malloc is on both libs handled in an internal way.

>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.

there is poolmem prog attached in tlsf mem that fix so pools work fast too.but can not use with AFA because poolmem on AFA is same as MOS and AROS and support MEMF_SEMPROTECT flag to make mempools thread safe.
 

Offline wawrzon

Re: new ixemul V62.1 for 68k.
« Reply #81 on: November 19, 2009, 07:19:45 PM »
Quote

there is poolmem prog attached in tlsf mem that fix so pools work fast too.but can not use with AFA because poolmem on AFA is same as MOS and AROS and support MEMF_SEMPROTECT flag to make mempools thread safe.

right, no problem i could turn off afaos, muforce, and copymempatch if need be, and turn the tlsfmem and tlsfmempool on in my s-s for the sake of testing. but would the speedup be measurable. i mean, in real world performance, not after hours and days of messing with the system to maximize memory fragmentation. i expect not. whadda ya think?
 

Offline itix

  • Hero Member
  • *****
  • Join Date: Oct 2002
  • Posts: 2380
    • Show only replies by itix
Re: new ixemul V62.1 for 68k.
« Reply #82 on: November 20, 2009, 06:40:15 AM »
Quote
I watch out for news of Hyperion Secret Project on their Webpage.maybe they do memory protection... ;-)

Then existing Amiga software is not going to work anyway. So...

Quote
but anyway, a Function that set and get Task user Pointer is the cleanest solution so nobdy need hack in the task structure.

But the task structure is already public. Adding Set/GetTaskUserData() is not going to change anything. There is no way you could add non-co-operative memory protection, there is no way you could get existing software support new APIs, the whole Amiga API is flawed anyway.
My Amigas: A500, Mac Mini and PowerBook
 

Offline bernd_afaTopic starter

  • Sr. Member
  • ****
  • Join Date: Nov 2005
  • Posts: 479
    • Show only replies by bernd_afa
Re: new ixemul V62.1 for 68k.
« Reply #83 on: November 20, 2009, 11:37:21 AM »
>Adding Set/GetTaskUserData() is not going to change anything

it change in that way, that there is no reason to access the task structure direct.
and this is really not more additional work.

normaly you need write

struct Task * task = FindTask(0);
task->tc_UserData = dat;

or write

SetTaskUserData(FindTask(0),dat);

thats really a stupid reason, to do lots work to make a Unix soft working with libnix.and when you accidently destroy userdata by wrong written program is notice soon.

I still ask several times and i still have no link see of ffmpeg for MOS to see how much work it was or where can download a list of functions MOS libnix support.then we can see how much more functions ixemul V62 support.

A good api should always have a list of functions it support when there is no source here so can see in source what functions it support.ANd that a OS need register to download a SDK is also bad.

I think changing a big Unix program to work with libnix is lots more work than use a function

SetTaskUserData(FindTask(0),dat);

or so.

also i told you ixemul can easy change to use tc_taskTrap instead of tc_TaskUserData.

Then i maybe do that so tc_userdata is free.

>is no way you could add non-co-operative memory protection, there is no way you could >get existing software support new APIs

but when enhance a Unix program to use AOS its a new program and so can very easy avoid to use tc_userdata.there need lots more programing work to get a Big unix program with libnix MOS working i think.

You still have not told where in netsurf you access tc_userdata.I find no place when i search whole files
« Last Edit: November 20, 2009, 12:04:52 PM by bernd_afa »
 

Offline Fab

  • Full Member
  • ***
  • Join Date: Jun 2009
  • Posts: 217
    • Show only replies by Fab
Re: new ixemul V62.1 for 68k.
« Reply #84 on: November 20, 2009, 01:37:00 PM »
Quote from: bernd_afa;530446
thats really a stupid reason, to do lots work to make a Unix soft working with libnix.and when you accidently destroy userdata by wrong written program is notice soon.

I still ask several times and i still have no link see of ffmpeg for MOS to see how much work it was or where can download a list of functions MOS libnix support.then we can see how much more functions ixemul V62 support.

A good api should always have a list of functions it support when there is no source here so can see in source what functions it support.ANd that a OS need register to download a SDK is also bad.

I told you there was nothing particularly interesting in these changes. Just implemented cbrtf and round and fix some bsdsocket stuff (close->closesocket and ioctl->ioctlsocket).

The list of supported functions is available in the headers and link libs. And the SDK is available for download on morphos-files.net.
« Last Edit: November 20, 2009, 01:55:22 PM by Fab »
 

Offline itix

  • Hero Member
  • *****
  • Join Date: Oct 2002
  • Posts: 2380
    • Show only replies by itix
Re: new ixemul V62.1 for 68k.
« Reply #85 on: November 20, 2009, 01:53:47 PM »
Quote
normaly you need write

struct Task * task = FindTask(0);
task->tc_UserData = dat;

or write

SetTaskUserData(FindTask(0),dat);

This is only little bit more useful than using AllocDosObejct() to allocate FileInfoBlock. Luckily your version does not have return code.

Quote
I think changing a big Unix program to work with libnix is lots more work than use a function

You might thinks so but it isnt so. Not with MorphOS libnix.

Quote
also i told you ixemul can easy change to use tc_taskTrap instead of tc_TaskUserData.

But maybe I am using tc_TrapData field for my own purposes. Unlikely but possible.

Quote
there need lots more programing work to get a Big unix program with libnix MOS working i think.

Usually problems lie on path handling. They default to /usr/ or parse paths in Unix way. If I was using ixemul I would have to do that anyway because it is not very nice when users start getting "Please insert volume usr: to any drive" requesters. Unless it is GeekGadgets port which requires GG environment anyway.

Another big problem is porting dependencies which sometimes takes over five minutes. Five hours if I create shared library out of it.
« Last Edit: November 20, 2009, 01:57:30 PM by itix »
My Amigas: A500, Mac Mini and PowerBook
 

Offline bernd_afaTopic starter

  • Sr. Member
  • ****
  • Join Date: Nov 2005
  • Posts: 479
    • Show only replies by bernd_afa
Re: new ixemul V62.1 for 68k.
« Reply #86 on: November 20, 2009, 03:53:17 PM »
>Another big problem is porting dependencies which sometimes takes over five minutes. >Five hours if I create shared library out of it.

there is ixlibray that allow easy automatic create of Unix libs.have not done it yet, because static is most time ok when there is no free time.megacz have done a new ixlibrary sdk and do some libs.see here.

http://megacz.back2roots.org/portsbttr.html

make a unix lib for MOS seem lots work.OS4 support sobj, dont know if that work fully automatic, but when look OS4 seem have most unix dynamic link libs.

>The list of supported functions is available in the headers and link libs. And the SDK is >available for download on morphos-files.net.

You mean here ?

http://www.morphos-files.net/categories/development/C

I see no headers for this.i search for atanf not find.

I find some defines but i hope the MOS devs know, this defines do not work with offical C++ stdlibc++.

they need the real thing because they do undef all

#define LOG10       ((double) 2.302585092994046)
#define FPTEN       ((double) 10.0)
#define FPONE       ((double) 1.0)
#define FPHALF      ((double) 0.5)
#define FPZERO      ((double) 0.0)
#define trunc(x)    ((int) (x))
#define round(x)    ((int) ((x) + 0.5))
#define itof(i)     ((double) (i))

#define fabs        IEEEDPAbs
#define floor       IEEEDPFloor
#define ceil        IEEEDPCeil

#define tan         IEEEDPTan
#define atan        IEEEDPAtan
#define cos         IEEEDPCos
#define acos        IEEEDPAcos
#define sin         IEEEDPSin
#define asin        IEEEDPAsin
#define exp         IEEEDPExp
#define pow(a,b)    IEEEDPPow((b),(a))
#define log         IEEEDPLog
#define log10       IEEEDPLog10
#define sqrt        IEEEDPSqrt

#define sinh        IEEEDPSinh
#define cosh        IEEEDPCosh
#define tanh        IEEEDPTanh

see cmath file

#include

// Get rid of those macros defined in in lieu of real functions.
#undef abs
#undef div
#undef acos
#undef asin
#undef atan
#undef atan2
#undef ceil
#undef cos
#undef cosh
#undef exp
#undef fabs
#undef floor
#undef fmod
#undef frexp
#undef ldexp
#undef log
#undef log10
#undef modf
#undef pow
#undef sin
#undef sinh
#undef sqrt
#undef tan
#undef tanh

>Usually problems lie on path handling. They default to /usr/ or parse paths in Unix way.

and again, do you not think its easy possible to switch this file translation off ?
I think it can easy done.
 

Offline bernd_afaTopic starter

  • Sr. Member
  • ****
  • Join Date: Nov 2005
  • Posts: 479
    • Show only replies by bernd_afa
Re: new ixemul V62.1 for 68k.
« Reply #87 on: November 20, 2009, 05:21:05 PM »
I donwload also the file for vbcc.

http://www.morphos-files.net/remote/VBCC,_MorphOS_target

this also contain only very few API funcs.for example math.h is only this

/* math.h - PowerPC */

#ifndef __MATH_H
#define __MATH_H 1

extern const char __infinity[];
#define HUGE_VAL (*(const double *)(const void *)__infinity)

double sin(double);
double cos(double);
double tan(double);
double sinh(double);
double cosh(double);
double tanh(double);
double asin(double);
double acos(double);
double atan(double);
double exp(double);
double log(double);
double log10(double);
double pow(double,double);
double sqrt(double);
double ceil(double);
double floor(double);
double fabs(double);
double atan2(double,double);
double ldexp(double,int);
double frexp(double,int *);
double modf(double,double *);
double fmod(double,double);

#ifndef __NOINLINE__
double __asm_fabs(__reg("f1") double) = "\tfabs\t1,1";
#define fabs(x) __asm_fabs(x)
#endif

#endif
 

Offline bernd_afaTopic starter

  • Sr. Member
  • ****
  • Join Date: Nov 2005
  • Posts: 479
    • Show only replies by bernd_afa
Re: new ixemul V62.1 for 68k.
« Reply #88 on: November 20, 2009, 07:21:59 PM »
Here is math.h what ixemul support

__BEGIN_DECLS
double   acos __P((double));
double   asin __P((double));
double   atan __P((double));
double   atan2 __P((double, double));
double   ceil __P((double));
double   cos __P((double));
double   cosh __P((double));
double   exp __P((double));
double   fabs __P((double));
double   floor __P((double));
double   fmod __P((double, double));
#define fmodl fmod
double   frexp __P((double, int *));
double   ldexp __P((double, int));
double   log __P((double));
double   log10 __P((double));
double   modf __P((double, double *));
double   pow __P((double, double));
double   sin __P((double));
double   sinh __P((double));
double   sqrt __P((double));
float   sqrtf __P((float));
double   tan __P((double));
double   tanh __P((double));

#if !defined(_ANSI_SOURCE) && !defined(_POSIX_SOURCE)
double   acosh __P((double));
double   asinh __P((double));
double   atanh __P((double));
double   cabs();      /* we can't describe cabs()'s argument properly */
//double   cbrt __P((double));
double   copysign __P((double, double));
double   drem __P((double, double));
double   erf __P((double));
double   erfc __P((double));
double   expm1 __P((double));
int   finite __P((double));
double   hypot __P((double, double));
#if defined(vax) || defined(tahoe)
double   infnan __P((int));
#endif
double   j0 __P((double));
double   j1 __P((double));
double   jn __P((int, double));
double   lgamma __P((double));
double   log1p __P((double));
double   logb __P((double));
double   rint __P((double));
double   scalb __P((double, int));
double   y0 __P((double));
double   y1 __P((double));
double   yn __P((int, double));
long lrintf __P((float));
long lrint __P((double));
float roundf __P((float));
double round __P((double));
double   log2 __P((double));
float truncf __P((float));
double trunc __P((double));
__math_decl int lroundf(float x)
__math_decl int lround(double x)
__math_decl float ceilf(float x)
__math_decl float floorf(float x)
__math_decl float frexpf(float x,int * exp)
__math_decl float ldexpf(float x,int exp)

#define signbit(x) ((x) < 0)
__math_decl float powf(float x,float y)
__math_decl float sinf(float x)
__math_decl float cosf(float x)
__math_decl float fmodf(float x,float y)
__math_decl float atan2f(float x,float y)
__math_decl float atanf(float x)
__math_decl double cbrt(double x)
__math_decl float cbrtf(float x)
 

Offline Fab

  • Full Member
  • ***
  • Join Date: Jun 2009
  • Posts: 217
    • Show only replies by Fab
Re: new ixemul V62.1 for 68k.
« Reply #89 on: November 20, 2009, 09:43:34 PM »
What about downloading the actual SDK instead of VBCC?

And what the f*ck with ixlibrary and shared objects. If you want an unix clone, why don't you switch to the real thing. At least it will work properly.
« Last Edit: November 20, 2009, 09:52:35 PM by Fab »