One of the basic rules of benchmarking anything is to remove the uncertainty or your results will be totally useless. Everyone and their cousin knows this...
it count not the exact time, because in real world internet load time can differ around 1-2 sec on fast server(as the netsurf and other sites i name are.)
Everybody knows that when a page on a amiga/ winbrowser can load in 1-2 sec and OWB need for this 90sec(without java script), then the influence of internet acess is about 1-2% at overall time, or something is bad in code.
and only this value is usefull how much slower it is in compare to aweb or OWB and if it is usefull
>Have you actually figured out why it crashes? Surely developer of >your skill is able to do this?
i have no time and fun to do so, Artur build first libnix and ixemul version too that crash.I look on both, but soon i notice libnix crash earlier.
When i port a Unix program i choose always the best solution.and this is not use libnix and add the missing functions, this is use a bsd kernel on amiga os, (ixemul)
>After that, the very first move is to get rid of ixemul usage. It just >will not work reliably with AmigaOS code.
and wy not ?
you cant compare MOS ixemul with 68k ixemul.
MOS ixemul have 2 very bad bugs, that make it very unstable, i find and fix that.i can tell you what places make problems.
when you use pngcrush and a picture that ami_stuff send me, and the MOS largeread code is enable, then there is extrem slowdown (more than 10*).it happen only on 1 picture.i deactivate that(ixmeul V48 have this code not) and all work ok
#if LARGEREADS
r = fp->_r;
/* TODO: should limit to specific buffering modes? - Piru */
if (resid >= r + fp->_bf._size) {
/* empty current buffer first, if a
--------------------
then next is,
in __write.c last MOS source have disable IXTTY_RAW.
line in V48 was this.
#define TTY_NLCR_ENABLE (IXTTY_RAW | IXTTY_OPOST | IXTTY_ONLCR)
when do a fh = open(audio:xxxxxxx) and do write(fh,buf,len)
give crap audio data hear on ahi.
use the V48 code fix that.
also i get now information wy ixemul V48 cant work on MOS even if MOS is called that it can execute 68k software.
its due to emulation bug.yes i call it a Bug, because when the AOS supervisor call is not support by 68k then MOS should nicely stop the program and tell supervisor is not support on 68k.
here is log output i get from a user and symbolinfo is in ixemul in.Here you can verify yourself hits come from supervsior if you dont believe that.
-> mlnet Hunk 1 Offset 0x000d0fe8
PPCStackFrame History:
StackFrame[ 0].LR-> Address 0x25660c70 -> mlnet Hunk 1 Offset 0x000c46d0
StackFrame[ 1].LR-> Address 0x25661860 -> mlnet Hunk 1 Offset 0x000c52c0
StackFrame[ 2].LR-> Address 0x2566d5bc -> mlnet Hunk 1 Offset 0x000d101c
StackFrame[ 3].LR-> Address 0x25668efc -> mlnet Hunk 1 Offset 0x000cc95c
StackFrame[ 4].LR-> Address 0x25668f50 -> mlnet Hunk 1 Offset 0x000cc9b0
StackFrame[ 5].LR-> Address 0x2565c2dc -> mlnet Hunk 1 Offset 0x000bfd3c
StackFrame[ 6].LR-> Address 0x2565c3e0 -> mlnet Hunk 1 Offset 0x000bfe40
StackFrame[ 7].LR-> Address 0x22f0bd58 -> MOSSYS:LIBS/ixemul.library Hunk 1 Offset 0x000088f0
StackFrame[ 8].LR-> Address 0x22f156b8 -> MOSSYS:LIBS/ixemul.library Hunk 1 Offset 0x00012250
StackFrame[ 9].LR-> Address 0x22f0bc1c -> MOSSYS:LIBS/ixemul.library Hunk 1 Offset 0x000087b4
StackFrame[10].LR-> Address 0x10121970 -> Module Hunk 0 Offset 0x00021970
StackFrame[11].LR-> Address 0xdeadfee1 **Not Valid**
MOS ixemul use that code and i guess its a bad hack and can break compatibility, when just set sr to 0 instead of getting the correct value.
#ifdef NATIVE_MORPHOS
sr = 0;
#else
/*#ifdef MORPHOS
if (has_morphos)
sr = 0;
else
#endif*/
{
asm volatile (" \n\
movel a5,a0 \n\
lea Lget_sr,a5 \n\
movel 4:w,a6 \n\
jsr a6@(-0x1e) \n\
movel a1,%0 \n\
bra Lskip \n\
Lget_sr: \n\
movew sp@,a1 | get sr register from the calling function \n\
rte \n\
Lskip: \n\
movel a0,a5 \n\
" : "=g" (sr) : : "a0", "a1", "a6");
}
#endif
I change ixemul now on two places to use AOS command.setsr.
important is that use gcc inline LPT stubs to not change flags on call
sr=SetSR(0,0);
and some tests show this place make no problems.ixemul V61.2 contain now no supervisor calls.
now problem when run under MOS is ixpipe.the MOS version have add code and fake a wbstartupmessage, because MOS ixemul want read on ixpipe-handler wbstartupmessage.
fake a message i think is a unclean solution and i dont want 2 diffrent ixpipes to test more easy with V48 and V50 and above.
/* pr_CLI is NULL since we are a handler, so ix_open will expect a wb message. Fake one. */
port.mp_Flags = PA_IGNORE;
NEWLIST(&port.mp_MsgList);
msg.sm_Message.mn_ReplyPort = &port;
msg.sm_Process = &me->pr_MsgPort;
msg.sm_NumArgs = 0;
msg.sm_ToolWindow = NULL;
msg.sm_ArgList = 0;
PutMsg(&me->pr_MsgPort, &msg.sm_Message);
ixbase = (APTR)OpenLibrary ("ixemul.library", NEEDED_IX_VERSION);
------
so new ixemul version need also correct ixpipe 68k for now.
more progress reports i dont get, but MOS OS4 is promotet to have a 68k emul and so it should execute 68k code and nothing else is ixemul.
