From: Dave Chapman <dave_at_dchapman.com>
Date: Thu, 10 May 2007 12:47:39 +0100

Christian Gmeiner wrote:
> 2007/5/10, Dave Chapman <dave_at_dchapman.com>:
>> I don't see how that will happen - won't it just mean replacing "#ifdef
>> SIMULATOR" with "#ifdef SDL_TARGET" ?
>
>
> No you are wrong.. we will use the target tree feature:
> firmware/target/sdl/*

How would adding a new target help with all the use of #ifdef SIMULATOR
in apps/ and the non target-tree parts of firmware/ ?

It's this high-level (i.e. not target-tree) code which has the most
instances of #ifdef SIMULATOR.

>>
>> Looking at the current code, there seem to be a lot of #ifdef SIMULATOR
>> checks which are not needed - e.g. lines of the form:
>>
>> #if defined(CPU_COLDFIRE) && !defined(SIMULATOR)
>>
>> can just be changed to:
>>
>> #ifdef CPU_COLDFIRE
>>
>> - the CONFIG_CPU macro in the config files aren't defined for the
>> simulator.
>>
>> Another problem is simply hardware features of targets which are not
>> implemented in the sim - mainly the MAS on Archos devices, radio,
>> recording, plus various other things like HAVE_PWM_BACKLIGHT_FADING.
>> How would your proposal deal with these?
>
>
> I dont want to write an emulator, I want to integrate the simulator
> better into the current source! These are two _very_ different things.

I didn't mention anything about writing an emulator. I'm talking about
the fact that there are many features which work on the target but not
in SDL, which is the reason for many of the #ifdefs you want to remove.

In order to get rid of those #ifdefs, you would either need to implement
the features for your SDL target (something you could just do now), or
remove the relevant HAVE_ macro from the config file and hence remove
all trace of the feature from the UI (again, something you can do now).

> We can run now rockbox on our pc with sdl.. we will use sdl to play
> sound and so on. But you have now the same core (threading,..) as we
> would compile rockbox for a target, which can help debugging.

The kernel and threading isn't part of target-tree, so your suggestion
isn't a pre-requisite for making the sim use the same core kernel as the
targets.

I agree that it would be great if the simulator used the same kernel as
the targets, but the problem is how to implement the hardware-specific
parts of the kernel in a portable way using SDL. A problem that still
exists if the SDL code is in target-tree.

>> I'm not convinced that a radical change in architecture is needed - the
>> time might be better spent just implementing more features in the
>> current sim, and ensuring #ifdef SIMULATOR is only being used when it
>> absolutely has to be.
>
>
> Believe me that nobody wants to check, if this ifdef is okay or not...
> its much easier when there are none or a very small amout of these
> #ifdef SIMULATOR.

That's what I'm saying - people have been mistakenly adding #ifdef
SIMULATOR when it's not needed, or adding it as a quick fix instead of
implemnting things for the simulator.

I can't see how this will change with a target-tree approach - either
you need to implement things in SDL, or the sim will continue to not
behave the same as the real device.

I'm not saying that moving the SDL code into target-tree is a bad idea,
just that I don't think it will make the huge difference you think it will.

Dave.
Received on 2007-05-10