Odyssey 1.23 progress: r5 RC2

@kas1e

Quote:

This is exactly what Jörg wrote. Peeking at address 4 is in fact causing a DSI exception, but this is handled silently by the kernel. The point is that exceptions cause a major performance penalty, even if they don't become visible.

Peeking at address 4 must be supported, because this was documented to be valid since day zero of Amiga history. But there are lots of other ways to get a valid ExecBase address which don't require this kind of a big wooden hammer and hence don't cause any further performance penalty.

@Thore
Ok, got it.

Through in whole odysseys code it uses 1 time, in that bcsharedtimermorphos.cpp , and i not see SysBase uses later directly in any place.

@kas1e

A one-time-appearance of it within the whole code doesn´t necessarily mean that it is called only that one time.

Please, just replace it with anything suitable and go on making Odyssey work

Searching in google I got:

http://code.google.com/p/os4sdl/sourc ... aos4/SDL_os4timer.c2?r=30

http://code.google.com/p/os4sdl/sourc ... gaos4/SDL_os4timer.c?r=30
<pre>..
void __os4timer_startup(void)
{
struct ExecBase *sysbase = (struct ExecBase*) IExec->Data.LibBase;
// struct ExecBase *sysbase = (struct ExecBase *)4L;
// IExec=sysbase->MainInterface;
..</pre>
So maybe replacing/#ifdef with such code will solve it.

@whose
Quote:

Please, better to understand why we need to replace it at all and not remove it :)

After talking with Thore in mail, suitable there is not have it at all as startup code already deal with. I also do search on all the os4codes i have, and on wiki/os4coding/hp forum, and no one assign Sysbase directly at all, everyone just have "extern struct ExecBase *SysBase;" and leave it to system to decide what is it.

So, my suitable replace is just:

@kas1e

Yes, this is suitable and the (IMHO) best solution.

We needed to replace it, because SysBase = *((struct ExecBase **) 4); does a zeropage access (from "user space"), which shouldn´t have been done at all...

Removing is impossible, because sometimes you need an anchor to access OS functions. On other systems this is done e.g. using an interrupt.

I don´t know why it is used in this part of code, but I don´t think that it´s done just for fun

@kas1e

“extern” does not make sense, this is what you use when, you want to tell the compiler that we have variable, but sense its a global, we can't declare it here. But its declared else where.

So drop the "extern", it does not make sense inside TimerFunc()

When you have more then one .o file, you can get linking error, saying the variable is declared more then once, this when you use “extern”.

besides, processes created by CreateNewProc, should call functions and it this agreements.

Int32 rc = _start(STRPTR args, int32 Length, APTR Execbase);

so go looking for Execbase on address 4 should be unnecessary.

CreateTask does not have a Execbase as argument but, instead it can be provided by AT_Param1 or AT_Param2 tags in tag list.

Or do what Jabirulo is saying.

@Whose
Quote:

Removing from os ? From odyssey we can remove it (i assume) because startup code already deal with SysBase, its always on the need it value, and no needs to set it at all for us.

Quote:

Like i know it :) All i know that SysBase automatically initialized by the startup code, and there no needs for us to have that "SysBase = anything".

What i mean is that even if Fab put it here for reason, for us it not need it as startup code deal with it already.

@LveForIt

Yeah, already removed it all and already tested all is fine.

@kas1e

Quote:

Since it's not explicity referenced, the only reason must be allow exec.library calls, but that seems odd as if this is in the main code you allready have it set up (even in Morphos I would guess) perhaps it's just got coppied over from another project by accident?

If this were in a loadable module of somekind with no startup code then it would need to be followed by code obtaining IExec from it, but doesn't appear to be the case.

@kas1e

One way you can manage the process is by a counter.

Count up when process start, count down when process ends, so at end of program you can see if count is 0 or not, and you know if process has stoped, then maybe you should do a IDOS->Delay(5), to make shore they are really stooped.



And use a MUTEX to protect the counter, if you need to make it atomic.

@LiveForIt

Facepalms!

while(process_count > 0)
{
IExec->Wait(SIGF_CHILD);
}

@broadblues

Well your the experts, I'm only do what I know works.

@LiveForIt

Quote:

Hmm... if it´s the SysBase defined by the startup code, the "extern" makes perfect sense here. SysBase is defined "elsewhere", and it should not be a local (automatic) variable of TimerFunc(). That´s what "extern" means here.

But what about this code running outside the main code´s scope?

I think that´s the reason for the "SysBase = *((struct ExecBase **) 4);" thingie. SysBase is declared inside the function (as a local, and here the "extern" indeed doesn´t make any sense. "static" would be the better choice, maybe) and must therefore be initialized with something that makes sense...

But if this is a function running within the main code´s scope only, it´s total nonsense to declare SysBase over and over. Bad coding practice

@whose

So what happens then does a local variable become global?
Way declare it as local variable, when its already global.

No it does not make sense, I never seen it used like that.

Maybe you should have read the next line I wrote not just the two first lines.

@LiveForIt

Sometimes it depends on the source code organization. If the files containing the whole code are organized in static modules, (global) variables like SysBase might not be visible within a certain file if they are not declared "extern".

If you don´t want to mix machine dependend code with "portable" code, it´s best practice not to mess up the "portable" code with machine dependend globals.

Locals must be initialized local, if you don´t declare them "extern" (and define the variable containing the needed value elsewhere). If the "local" variable is declared "extern", this does indeed mean that it´s a global. That´s what SysBase is in most cases. A global. For OS4, it´s a variable defined by the startup code.

Here (in this function TimerFunc() ) it is a question of context, if "extern" makes sense or if the local declaration of SysBase is meant for "clean" code.

If the function is running within the scope of the startup module, "extern" makes perfect sense (and it would lead most certainly to a crash, if you discard the "extern" qualifier). But in this case the initialization is unnecessary. SysBase is initialized already (by the startup module).

If it´s running outside this scope, the correct value of SysBase should be provided by parameter and could be used directly then.

Back in 68k times it was quite usual to initialize a local SysBase by "SysBase = *((struct ExecBase **) 4); " (although most today´s compiler´s startup code provides for SysBase), but with the advent of zeropage protection, this is bad practice.

For me, this function´s code looks a bit messy. On the one hand, global SysBase is used (MOS and OS4 port), on the other hand, "bootstrap" initialization of SysBase is used (obviously, meant for 68k systems). The scope is quite unclear here...

Edit: If the code compiles without the "extern" AND without the initialization, there must be a global SysBase already somewhere within the source file. But then it should throw at least a warning about redefinition... weird.

@Andy
Quote:
Via ranger all i can see, is that on first run it creates (as usuall, and same for 1.16) those process:

Quote:

When i exit, all of them exit too. All seems fine.

Then i run second instance from shell : dsi, ignoring of which run those processes again fine and browser works. Just after i ignore DSI i have on serial:

Quote:

From that info you ought to be able to see in ranger which app that task belongs too.

Does the DSI not give any kind of stack trace? Maybe you posted allready and I missed it.

Have you tried running this from gdb? I know it has it's limitations but it might still catch something...

@Andy
Quote:

http://kas1e.mikendezign.com/temp/ranger.jpg

Quote:




Also do check this way: i just run odyssey from shell, exit, close that shell window, spawn new one, run odyssey : all works (but that expected, as it kind of new instance).

Running second time in new tab : works too.
Running third time in another tab: works too.

"endcli" in all tabs after i run second or third instance works fine, i can exit from them, etc (so no locked or whatever).

Only problem is exactly in the same shell window run/exit/run again.

Quote:

Well , as it will be inside of gdb, it will spawn for every new run new process and there will be no crash :) (as it didn't crashes for as in all places, only direct run from the same shell window in the same tab). Or you mean attach to gdb when its already crashed ? Tried as well, backtrace / bt just show some mess. Or if you mean to do so because dind't see crashlog : nope, our reaper catch it fine, i even post it before and recopy it in that post again.

@whose

Quote:

It'll quite happily compile without error that way under OS4 as the SysBase variable is not access directly ( functuion calls are using IExec) (if -wall is in use it might throw up an warning about it being unused)

@Fab
Quote:

But it just happens when i only run odyssey , do nothing (so only about: page), quit, and run it again. At thise moment imho only few threads involved (those which was in 1.16 as well) ?