Supporting ubicom SX28/48/52 under Gideon

Caleb Tennis caleb at
Mon Oct 7 19:38:08 UTC 2002

On Monday 07 October 2002 03:37 pm, Kuba Ober wrote:

> Now the questions are:
> 1. I presume that assembler would better stay commandline just as it is.
> Parallax syntax it is a rather simple assembly syntax, so it's parsing is
> very fast. Thus the assembler does everything in a single program (i.e. it
> doesn't need or provide an external linker -- all the needed sources are
> included and it provides final .hex and .lst files). 2k lines assembly
> takes about 0.2 seconds on a PIII/450.


> 2. As far as the debugger is concerned, should I:
> - keep it as commandline-only and write some kind of gideon plugin for it,
> or - separate the guts as a library and provide commandline-ui and
> gideon-plugin ui's that depend on that lib?

You can do it either way, but keeping it command line only would probably be 
simpler.  Gideon's CVS part, for example, accesses the command line cvs stuff 
for "behind the scenes" work.

> 3. The debugger is obviously architecture-specific, so for gideon UI things
> like register/memory windows etc. need to be made from scratch. What is the
> place they should go to in the source tree (more or less)?

You'll want to create a new part, perhaps in parts/ubicomsx or something like 
that.  Read the HACKING file that explains what you need to get to get a part 
working, and then copy one of the other parts as far as their setup goes.

> 4. Programmer: programming belongs more or less to the same category as run
> and debug does, because you need assembled files to do it. Does gideon
> provide enough menu flexibility to add actions to the menus (like to debug
> menu, whatever).

Yes, the debugger front end, for example, create a "Debug" menu entry when the 
part is loaded.  The appwizard part adds the "New Project" ability to the 
existing Project menu.

> 5. Does gideon support multiple targets in the same project? My reasoning
> is that I usually have some simple embedded things plus a simple qt or kde
> gui for them -- it would make sense to have them in the same project.

Yes, through Automake/ support.  I'm not familiar with other 
methods, but qmake support I believe is functioning.


More information about the KDevelop-devel mailing list