trouble with porting architecture

trouble with porting architecture

[James Dessart]

I've been working with an architecture port made in '97, which was 
updated to 2.95 by someone else, then I updated it to 3.1.  The 
architecture in question is the m6809, running in a Tandy Color 
Computer.  It works for most source, but I've come across a piece of 
source which generates the following error:

../contiki/ctk/ctk-conio.c: In function `ctk_draw_menus':
../contiki/ctk/ctk-conio.c:510: unable to generate reloads for:

(insn 99 98 100 (set (reg:QI 0 d [32])
         (minus:QI (reg:QI 33)
             (reg:QI 0 d [34]))) 31 {subqi3} (nil)
     (expr_list:REG_DEAD (reg:QI 33)
         (expr_list:REG_DEAD (reg:QI 0 d [34])
             (nil))))
../contiki/ctk/ctk-conio.c:510: Internal compiler error in 
find_reloads, at reload.c:3576

Would this indicate a problem in the machine description?  Or something 
else?  The code is really rather straightforward, and doesn't generate 
any warnings.  The function in question returns nothing, and has a 
single local variable.

Unfortunately, I'm not too familiar with gcc internals, and couldn't 
write a machine description to save my life.  I understand the basic 
concepts, but that's about it.

See function below:

void
ctk_draw_menus(struct ctk_menus *menus)
{
   struct ctk_menu *m;

   /* Draw menus */
   textcolor(MENUCOLOR);
   gotoxy(0, 0);
   revers(1);
   cputc(' ');
   for(m = menus->menus->next; m != NULL; m = m->next) {
     if(m != menus->open) {
       cputs(m->title);
       cputc(' ');
     } else {
       draw_menu(m);
     }
   }


   if(wherex() + strlen(menus->desktopmenu->title) + 1>= sizex) {
     gotoxy(sizex - strlen(menus->desktopmenu->title) - 1, 0);
   } else {
     cclear(sizex - wherex() -
	   strlen(menus->desktopmenu->title) - 1);
   }

   /* Draw desktopmenu */
   if(menus->desktopmenu != menus->open) {
     cputs(menus->desktopmenu->title);
     cputc(' ');
   } else {
     draw_menu(menus->desktopmenu);
   }

   revers(0);
}

James

Re: trouble with porting architecture

[Eric Botcazou]

> The architecture in question is the m6809, running in a Tandy Color
> Computer.  It works for most source, but I've come across a piece of
> source which generates the following error:
>
> ../contiki/ctk/ctk-conio.c: In function `ctk_draw_menus':
> ../contiki/ctk/ctk-conio.c:510: unable to generate reloads for:
>
> (insn 99 98 100 (set (reg:QI 0 d [32])
>          (minus:QI (reg:QI 33)
>              (reg:QI 0 d [34]))) 31 {subqi3} (nil)
>      (expr_list:REG_DEAD (reg:QI 33)
>          (expr_list:REG_DEAD (reg:QI 0 d [34])
>              (nil))))
> ../contiki/ctk/ctk-conio.c:510: Internal compiler error in
> find_reloads, at reload.c:3576
>
> Would this indicate a problem in the machine description?  Or something
> else?  The code is really rather straightforward, and doesn't generate
> any warnings.  The function in question returns nothing, and has a
> single local variable.

I think it is a consequence of the extremely low number of 8-bit registers
on the MC6809, which makes it difficult for GCC's register allocation
strategy (namely, the reload pass) to work reliably on this architecture.
I myself ran into the problem several times.

This insn shouldn't be problematic since the only transformation required to
match the constraints of the SUBA instruction is to spill (reg:QI 33) to
memory.  However the 16-bit D register, which is (partially) live before and
after the insn, consumes all 8-bit registers so this may trigger a
limitation of the reload pass.

> See function below:
>
> void
> ctk_draw_menus(struct ctk_menus *menus)
> {
>    struct ctk_menu *m;
>
>    /* Draw menus */
>    textcolor(MENUCOLOR);
>    gotoxy(0, 0);
>    revers(1);
>    cputc(' ');
>    for(m = menus->menus->next; m != NULL; m = m->next) {
>      if(m != menus->open) {
>        cputs(m->title);
>        cputc(' ');
>      } else {
>        draw_menu(m);
>      }
>    }
>
>
>    if(wherex() + strlen(menus->desktopmenu->title) + 1>= sizex) {
>      gotoxy(sizex - strlen(menus->desktopmenu->title) - 1, 0);
>    } else {
>      cclear(sizex - wherex() -
>    strlen(menus->desktopmenu->title) - 1);
>    }
>
>    /* Draw desktopmenu */
>    if(menus->desktopmenu != menus->open) {
>      cputs(menus->desktopmenu->title);
>      cputc(' ');
>    } else {
>      draw_menu(menus->desktopmenu);
>    }
>
>    revers(0);
> }

This is obviously not sufficient to reproduce the problem.  You need to
provide a preprocessed testcase, the GCC version, the options passed to the
compiler and so on (see http://gcc.gnu.org/bugs.html).  I'll try to further
help you, but not before the next week.

--
Eric Botcazou

Re: trouble with porting architecture

[Geert Bosch]

On Dec 30, 2003, at 12:30, Eric Botcazou wrote:
> I think it is a consequence of the extremely low number of 8-bit 
> registers
> on the MC6809, which makes it difficult for GCC's register allocation
> strategy (namely, the reload pass) to work reliably on this 
> architecture.
> I myself ran into the problem several times.

One common work around on that processor is to consider a few locations 
in
page zero (first 256 bytes of memory) as fake 16-bit registers (one or 
two),
since these locations are relatively cheap to load/store.

Re: trouble with porting architecture

[James Dessart]

[-- Attachment #1: Type: text/plain, Size: 2690 bytes --]


On 30-Dec-03, at 12:30 PM, Eric Botcazou wrote:

> This is obviously not sufficient to reproduce the problem.  You need to
> provide a preprocessed testcase, the GCC version, the options passed 
> to the
> compiler and so on (see http://gcc.gnu.org/bugs.html).  I'll try to 
> further
> help you, but not before the next week.

Hopefully this'll be of more help... sorry for the previous sparse and 
anemic report. :)

What's been discussed on the coco list is to use the direct-page mode, 
probably pointing at some predefined area, as an extra set of 
registers.  I'm not sure if page 0 is free on the CoCo, though.

[james@loki:contiki-coco] % gcc09 -v -save-temps -Wall -Iapps -Ictk 
-Iuip -Iconf -I../contiki/apps -I../contiki/ctk -I../contiki/ek 
-I../contiki/lib -I../contiki/uip -c ../contiki/ctk/ctk-conio.c
Reading specs from /usr/local/lib/gcc-lib/coco-rsdos/3.1.1/specs
Configured with: ../gcc-3.1.1/configure --target=coco-rsdos 
--program-suffix=09 --nfp --enable-obsolete
Thread model: single
gcc version 3.1.1
  /usr/local/lib/gcc-lib/coco-rsdos/3.1.1/cpp0 -lang-c -v -Iapps -Ictk 
-Iuip -Iconf -I../contiki/apps -I../contiki/ctk -I../contiki/ek 
-I../contiki/lib -I../contiki/uip -D__GNUC__=3 -D__GNUC_MINOR__=1 
-D__GNUC_PATCHLEVEL__=1 -Dmc6809 -DMC6809 -D__mc6809__ -D__MC6809__ 
-D__mc6809 -D__MC6809 -D__NO_INLINE__ -D__STDC_HOSTED__=1 
../contiki/ctk/ctk-conio.c -Wall ctk-conio.i
GNU CPP version 3.1.1 (cpplib) (MC6809)
ignoring nonexistent directory "NONE/include"
ignoring nonexistent directory "/usr/local/coco-rsdos/sys-include"
#include "..." search starts here:
#include <...> search starts here:
  apps
  ctk
  uip
  conf
  ../contiki/apps
  ../contiki/ctk
  ../contiki/ek
  ../contiki/lib
  ../contiki/uip
  /usr/local/lib/gcc-lib/coco-rsdos/3.1.1/include
  /usr/local/coco-rsdos/include
End of search list.
  /usr/local/lib/gcc-lib/coco-rsdos/3.1.1/cc1 -fpreprocessed ctk-conio.i 
-quiet -dumpbase ctk-conio.c -Wall -version -o ctk-conio.s
GNU CPP version 3.1.1 (cpplib) (MC6809)
GNU C version 3.1.1 (coco-rsdos)
         compiled by GNU C version Apple cpp-precomp 6.14.
../contiki/ctk/ctk-conio.c: In function `ctk_draw_menus':
../contiki/ctk/ctk-conio.c:510: unable to generate reloads for:
(insn 99 98 100 (set (reg:QI 0 d [32])
         (minus:QI (reg:QI 33)
             (reg:QI 0 d [34]))) 31 {subqi3} (nil)
     (expr_list:REG_DEAD (reg:QI 33)
         (expr_list:REG_DEAD (reg:QI 0 d [34])
             (nil))))
../contiki/ctk/ctk-conio.c:510: Internal compiler error in 
find_reloads, at reload.c:3576
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.


[-- Attachment #2: ctk-conio.i --]
[-- Type: application/octet-stream, Size: 19766 bytes --]

# 1 "../contiki/ctk/ctk-conio.c"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "../contiki/ctk/ctk-conio.c"
# 39 "../contiki/ctk/ctk-conio.c"
# 1 "../contiki/ctk/ctk.h" 1
# 54 "../contiki/ctk/ctk.h"
# 1 "conf/ctk-conf.h" 1
# 55 "../contiki/ctk/ctk.h" 2
# 1 "ctk/ctk-arch.h" 1
# 56 "../contiki/ctk/ctk.h" 2
# 1 "../contiki/ek/ek.h" 1
# 42 "../contiki/ek/ek.h"
# 1 "conf/ek-conf.h" 1
# 43 "conf/ek-conf.h"
# 1 "/usr/local/coco-rsdos/include/time.h" 1 3
# 12 "/usr/local/coco-rsdos/include/time.h" 3
# 1 "/usr/local/coco-rsdos/include/sys/types.h" 1 3
# 13 "/usr/local/coco-rsdos/include/sys/types.h" 3
typedef struct {
   int quot;
   int rem;
} div_t;

typedef struct {
   long int quot;
   long int rem;
} ldiv_t;


typedef long unsigned int size_t;

typedef unsigned int mode_t;

typedef signed int off_t;

typedef unsigned int ssize_t;

typedef unsigned int fpos_t;

typedef unsigned int clock_t;
# 13 "/usr/local/coco-rsdos/include/time.h" 2 3




extern clock_t clock(void);
# 44 "conf/ek-conf.h" 2

typedef void *ek_data_t;

typedef unsigned char ek_signal_t;
typedef unsigned char ek_id_t;






typedef unsigned short ek_ticks_t;



typedef unsigned long ek_clock_t;


typedef unsigned char ek_num_signals_t;


typedef unsigned char ek_num_timers_t;


typedef unsigned char ek_num_listeners_t;
# 43 "../contiki/ek/ek.h" 2
# 57 "../contiki/ek/ek.h"
typedef unsigned char ek_err_t;

ek_clock_t ek_clock(void);
# 57 "../contiki/ctk/ctk.h" 2

# 1 "../contiki/lib/cc.h" 1
# 48 "../contiki/lib/cc.h"
# 1 "conf/cc-conf.h" 1
# 49 "../contiki/lib/cc.h" 2
# 59 "../contiki/ctk/ctk.h" 2
# 84 "../contiki/ctk/ctk.h"
struct ctk_widget;
# 110 "../contiki/ctk/ctk.h"
struct ctk_separator {
  struct ctk_widget *next;
  struct ctk_window *window;
  unsigned char x, y;
  unsigned char type;
  unsigned char w, h;
};
# 136 "../contiki/ctk/ctk.h"
struct ctk_button {
  struct ctk_widget *next;
  struct ctk_window *window;
  unsigned char x, y;
  unsigned char type;
  unsigned char w, h;
  char *text;
};
# 164 "../contiki/ctk/ctk.h"
struct ctk_label {
  struct ctk_widget *next;
  struct ctk_window *window;
  unsigned char x, y;
  unsigned char type;
  unsigned char w, h;
  char *text;
};
# 192 "../contiki/ctk/ctk.h"
struct ctk_hyperlink {
  struct ctk_widget *next;
  struct ctk_window *window;
  unsigned char x, y;
  unsigned char type;
  unsigned char w, h;
  char *text;
  char *url;
};
# 240 "../contiki/ctk/ctk.h"
struct ctk_textentry {
  struct ctk_widget *next;
  struct ctk_window *window;
  unsigned char x, y;
  unsigned char type;
  unsigned char w, h;
  char *text;
  unsigned char len;
  unsigned char state;
  unsigned char xpos, ypos;
};
# 268 "../contiki/ctk/ctk.h"
struct ctk_icon {
  struct ctk_widget *next;
  struct ctk_window *window;
  unsigned char x, y;
  unsigned char type;
  unsigned char w, h;
  char *title;
  ek_id_t owner;
  unsigned char *bitmap;
  char *textmap;
};



struct ctk_bitmap {
  struct ctk_widget *next;
  struct ctk_window *window;
  unsigned char x, y;
  unsigned char type;
  unsigned char w, h;
  unsigned char *bitmap;
};






struct ctk_textmap {
  struct ctk_widget *next;
  struct ctk_window *window;
  unsigned char x, y;
  unsigned char type;
  unsigned char w, h;
  char *textmap;
  unsigned char flags;
  unsigned char state;
};





struct ctk_widget_button {
  char *text;
};




struct ctk_widget_label {
  char *text;
};




struct ctk_widget_hyperlink {
  char *text;
  char *url;
};

struct ctk_widget_textentry {
  char *text;
  unsigned char len;
  unsigned char state;
  unsigned char xpos, ypos;
};

struct ctk_widget_icon {
  char *title;
  ek_id_t owner;
  unsigned char *bitmap;
  char *textmap;
};

struct ctk_widget_bitmap {
  unsigned char *bitmap;
};
# 366 "../contiki/ctk/ctk.h"
struct ctk_widget {
  struct ctk_widget *next;


  struct ctk_window *window;

  unsigned char x,


    y;


  unsigned char type;






  unsigned char w,

    h;

  union {
    struct ctk_widget_label label;
    struct ctk_widget_button button;
    struct ctk_widget_hyperlink hyperlink;
    struct ctk_widget_textentry textentry;
    struct ctk_widget_icon icon;
    struct ctk_widget_bitmap bitmap;
  } widget;


};


struct ctk_desktop;
# 414 "../contiki/ctk/ctk.h"
struct ctk_window {
  struct ctk_window *next,


    *prev;

  struct ctk_desktop *desktop;


  ek_id_t owner;




  char *title;

  unsigned char titlelen;



  struct ctk_button closebutton;







  struct ctk_button titlebutton;







  unsigned char x,

    y;

  unsigned char w,

    h;



  struct ctk_widget *inactive;



  struct ctk_widget *active;



  struct ctk_widget *focused;



};




struct ctk_menuitem {
  char *title;
  unsigned char titlelen;

};




struct ctk_menu {
  struct ctk_menu *next;




  char *title;
  unsigned char titlelen;





  unsigned char nitems;

  unsigned char active;

  struct ctk_menuitem items[10];


};




struct ctk_menus {
  struct ctk_menu *menus;


  struct ctk_menu *open;


  struct ctk_menu *desktopmenu;




};







struct ctk_desktop {
  char *name;

  struct ctk_window desktop_window;

  struct ctk_window *windows;
  struct ctk_window *dialog;



  struct ctk_menus menus;
  struct ctk_menu *lastmenu;
  struct ctk_menu desktopmenu;


  unsigned char height,
    width;
# 570 "../contiki/ctk/ctk.h"
  unsigned char redraw;

  struct ctk_widget *redraw_widgets[8];
  unsigned char redraw_widgetptr;

  struct ctk_window *redraw_windows[8];
  unsigned char redraw_windowptr;

   unsigned char redraw_y1,
    redraw_y2;
};
# 590 "../contiki/ctk/ctk.h"
void ctk_init(void);
void ctk_mode_set(unsigned char mode);
unsigned char ctk_mode_get(void);



void ctk_window_new(struct ctk_window *window,
                    unsigned char w, unsigned char h,
                    char *title);
void ctk_window_clear(struct ctk_window *w);
void ctk_window_open(struct ctk_window *w);

void ctk_window_close(struct ctk_window *w);
void ctk_window_redraw(struct ctk_window *w);




void ctk_dialog_new(struct ctk_window *window,
                    unsigned char w, unsigned char h);
void ctk_dialog_open(struct ctk_window *d);
void ctk_dialog_close(void);


void ctk_menu_new(struct ctk_menu *menu, char *title);
void ctk_menu_add(struct ctk_menu *menu);
void ctk_menu_remove(struct ctk_menu *menu);
unsigned char ctk_menuitem_add(struct ctk_menu *menu, char *name);
# 633 "../contiki/ctk/ctk.h"
void ctk_icon_add(struct ctk_widget *icon, ek_id_t id);
# 645 "../contiki/ctk/ctk.h"
void ctk_widget_add(struct ctk_window *window,
                                struct ctk_widget *widget);
# 664 "../contiki/ctk/ctk.h"
void ctk_widget_redraw(struct ctk_widget *w);
# 813 "../contiki/ctk/ctk.h"
void ctk_desktop_redraw(struct ctk_desktop *d);
unsigned char ctk_desktop_width(struct ctk_desktop *d);
unsigned char ctk_desktop_height(struct ctk_desktop *d);


extern ek_signal_t ctk_signal_keypress,
  ctk_signal_widget_activate,
  ctk_signal_widget_select,
  ctk_signal_timer,
  ctk_signal_menu_activate,
  ctk_signal_window_close,
  ctk_signal_pointer_move,
  ctk_signal_pointer_button;
# 847 "../contiki/ctk/ctk.h"
extern ek_signal_t ctk_signal_button_activate,
  ctk_signal_button_hover,
  ctk_signal_hyperlink_activate,
  ctk_signal_hyperlink_hover;
# 40 "../contiki/ctk/ctk-conio.c" 2
# 1 "../contiki/ctk/ctk-draw.h" 1
# 137 "../contiki/ctk/ctk-draw.h"
void ctk_draw_init(void);
# 153 "../contiki/ctk/ctk-draw.h"
void ctk_draw_clear(unsigned char clipy1, unsigned char clipy2);
# 176 "../contiki/ctk/ctk-draw.h"
void ctk_draw_clear_window(struct ctk_window *window,
                           unsigned char focus,
                           unsigned char clipy1,
                           unsigned char clipy2);
# 205 "../contiki/ctk/ctk-draw.h"
void ctk_draw_window(struct ctk_window *window,
                     unsigned char focus,
                     unsigned char clipy1,
                     unsigned char clipy2);
# 224 "../contiki/ctk/ctk-draw.h"
void ctk_draw_dialog(struct ctk_window *dialog);
# 264 "../contiki/ctk/ctk-draw.h"
void ctk_draw_widget(struct ctk_widget *w,
                     unsigned char focus,
                     unsigned char clipy1,
                     unsigned char clipy2);

void ctk_draw_menus(struct ctk_menus *menus);




unsigned char ctk_draw_width(void);
unsigned char ctk_draw_height(void);
# 41 "../contiki/ctk/ctk-conio.c" 2

# 1 "ctk/ctk-conio-conf.h" 1
# 43 "../contiki/ctk/ctk-conio.c" 2

# 1 "ctk/conio.h" 1
# 47 "ctk/conio.h"
# 1 "../contiki/lib/libconio.h" 1
# 42 "../contiki/lib/libconio.h"
# 1 "conf/libconio-conf.h" 1
# 43 "../contiki/lib/libconio.h" 2



void ctk_arch_draw_char(char c,
                        unsigned char xpos,
                        unsigned char ypos,
                        unsigned char reversedflag,
                        unsigned char color);
# 68 "../contiki/lib/libconio.h"
unsigned char wherex(void);
unsigned char wherey(void);
void clrscr(void);
void bgcolor(unsigned char c);
void bordercolor(unsigned char c);
void screensize(unsigned char *x, unsigned char *y);
void revers(unsigned char c);
void cputc(char c);
void cputs(char *str);
void cclear(unsigned char length);
void chline(unsigned char length);
void cvline(unsigned char length);
void gotoxy(unsigned char x, unsigned char y);
void cclearxy(unsigned char x, unsigned char y, unsigned char length);
void chlinexy(unsigned char x, unsigned char y, unsigned char length);
void cvlinexy(unsigned char x, unsigned char y, unsigned char length);
void cputsxy(unsigned char x, unsigned char y, char *str);
void cputcxy(unsigned char x, unsigned char y, char c);
void textcolor(unsigned char c);
# 48 "ctk/conio.h" 2
# 45 "../contiki/ctk/ctk-conio.c" 2
# 1 "/usr/local/coco-rsdos/include/string.h" 1 3
# 15 "/usr/local/coco-rsdos/include/string.h" 3
extern void * memchr(const void *s, unsigned char c, size_t n);
extern int memcmp(const void *s1, const void *s2, size_t n);
extern void * memcpy(void *s1, const void *s2, size_t n);
extern void * memmove(void *s1, const void *s2, size_t n);
extern void * memset(void *s, unsigned char c, size_t n);
extern char * strcat(char *s1, const char *s2);
extern char * strchr(const char *s, unsigned char c);
extern int strcmp(const char *s1, const char *s2);
extern int strcoll(const char *s1, const char *s2);
extern char * strcpy(char *s1, const char *s2);
extern size_t strcspn(const char *s1, const char *s2);
extern char * strerror(int errnum);
extern size_t strlen(const char *s);
extern char * strncat(char *s1, const char *s2, size_t n);
extern int strncmp(const char *s1, const char *s2, size_t n);
extern char * strncpy(char *s1, const char *s2, size_t n);
extern char * strpbrk(const char *s1, const char *s2);
extern char * strrchr(const char *s, unsigned char c);
extern size_t strspn(const char *s1, const char *s2);
extern char * strstr(const char *s1, const char *s2);
extern char * strtok(char *s1, const char *s2);
extern size_t strxfrm(char *s1, const char *s2, size_t n);
# 46 "../contiki/ctk/ctk-conio.c" 2





static unsigned char sizex, sizey;


static char tmp[40];
static void
cputsn(char *str, unsigned char len)
{
  strncpy(tmp, str, len);
  tmp[len] = 0;
  cputs(tmp);
}

void
ctk_draw_init(void)
{
  bgcolor(0);
  bordercolor(0);
  screensize(&sizex, &sizey);
  ctk_draw_clear(0, sizey);
}

static void
draw_widget(struct ctk_widget *w,
            unsigned char x, unsigned char y,
            unsigned char clipx,
            unsigned char clipy,
            unsigned char clipy1, unsigned char clipy2,
            unsigned char focus)
{
  unsigned char xpos, ypos, xscroll;
  unsigned char i, j;
  char c, *text;
  unsigned char len;

  if(focus & 2) {
    textcolor(1);
    if(focus & 1) {
      textcolor(1);
    }
  } else if(focus & 4) {
    textcolor(1);
    if(focus & 1) {
      textcolor(1);
    }
  } else {
    textcolor(1);
  }

  xpos = x + w->x;
  ypos = y + w->y;

  switch(w->type) {
  case 1:
    if(ypos >= clipy1 && ypos < clipy2) {
      chlinexy(xpos, ypos, w->w);
    }
    break;
  case 2:
    text = w->widget.label.text;
    for(i = 0; i < w->h; ++i) {
      if(ypos >= clipy1 && ypos < clipy2) {
        gotoxy(xpos, ypos);
        cputsn(text, w->w);
        if(w->w - (wherex() - xpos) > 0) {
          cclear(w->w - (wherex() - xpos));
        }
      }
      ++ypos;
      text += w->w;
    }
    break;
  case 3:
    if(ypos >= clipy1 && ypos < clipy2) {
      if(focus & 1) {
        revers(1);
      } else {
        revers(0);
      }
      cputcxy(xpos, ypos, '[');
      cputsn(w->widget.button.text, w->w);
      cputc(']');
      revers(0);
    }
    break;
  case 4:
    if(ypos >= clipy1 && ypos < clipy2) {
      if(focus & 1) {
        revers(0);
      } else {
        revers(1);
      }
      gotoxy(xpos, ypos);
      textcolor(1);
      cputsn(w->widget.button.text, w->w);
      revers(0);
    }
    break;
  case 5:
    text = w->widget.textentry.text;
    if(focus & 1) {
      revers(1);
    } else {
      revers(0);
    }
    xscroll = 0;
    if(w->widget.textentry.xpos >= w->w - 1) {
      xscroll = w->widget.textentry.xpos - w->w + 1;
    }
    for(j = 0; j < w->h; ++j) {
      if(ypos >= clipy1 && ypos < clipy2) {
        if(w->widget.textentry.state == 1 &&
           w->widget.textentry.ypos == j) {
          revers(0);
          cputcxy(xpos, ypos, '>');
          for(i = 0; i < w->w; ++i) {
            c = text[i + xscroll];
            if(i == w->widget.textentry.xpos - xscroll) {
              revers(1);
            } else {
              revers(0);
            }
            if(c == 0) {
              cputc(' ');
            } else {
              cputc(c);
            }
            revers(0);
          }
          cputc('<');
        } else {
          cvlinexy(xpos, ypos, 1);
          gotoxy(xpos + 1, ypos);
          cputsn(text, w->w);
          i = wherex();
          if(i - xpos - 1 < w->w) {
            cclear(w->w - (i - xpos) + 1);
          }
          cvline(1);
        }
      }
      ++ypos;
      text += w->w;
    }
    revers(0);
    break;
  case 7:
    if(ypos >= clipy1 && ypos < clipy2) {
      if(focus & 1) {
        revers(1);
      } else {
        revers(0);
      }
      gotoxy(xpos, ypos);
      if(w->widget.icon.textmap != 0) {
        for(i = 0; i < 3; ++i) {
          gotoxy(xpos, ypos);
          if(ypos >= clipy1 && ypos < clipy2) {
            cputc(w->widget.icon.textmap[0 + 3 * i]);
            cputc(w->widget.icon.textmap[1 + 3 * i]);
            cputc(w->widget.icon.textmap[2 + 3 * i]);
          }
          ++ypos;
        }
      }
      x = xpos;

      len = strlen(w->widget.icon.title);
      if(x + len >= sizex) {
        x = sizex - len;
      }

      gotoxy(x, ypos);
      if(ypos >= clipy1 && ypos < clipy2) {
        cputs(w->widget.icon.title);
      }
      revers(0);
    }
    break;

  default:
    break;
  }
}

void
ctk_draw_widget(struct ctk_widget *w,
                unsigned char focus,
                unsigned char clipy1,
                unsigned char clipy2)
{
  struct ctk_window *win = w->window;
  unsigned char posx, posy;

  posx = win->x + 1;
  posy = win->y + 2;

  if(w == win->focused) {
    focus |= 1;
  }

  draw_widget(w, posx, posy,
              posx + win->w,
              posy + win->h,
              clipy1, clipy2,
              focus);




}

void
ctk_draw_clear_window(struct ctk_window *window,
                      unsigned char focus,
                      unsigned char clipy1,
                      unsigned char clipy2)
{
  unsigned char i;
  unsigned char h;


  h = window->y + 2 + window->h;

  for(i = window->y + 2; i < h; ++i) {
    if(i >= clipy1 && i < clipy2) {
      cclearxy(window->x + 1, i, window->w);
    }
  }
}

static void
draw_window_contents(struct ctk_window *window, unsigned char focus,
                     unsigned char clipy1, unsigned char clipy2,
                     unsigned char x1, unsigned char x2,
                     unsigned char y1, unsigned char y2)
{
  struct ctk_widget *w;
  unsigned char wfocus;


  for(w = window->inactive; w != 0; w = w->next) {
    draw_widget(w, x1, y1, x2, y2,
                clipy1, clipy2,
                focus);
  }


  for(w = window->active; w != 0; w = w->next) {
    wfocus = focus;
    if(w == window->focused) {
      wfocus |= 1;
    }

   draw_widget(w, x1, y1, x2, y2,
               clipy1, clipy2,
               wfocus);
  }





}

void
ctk_draw_window(struct ctk_window *window, unsigned char focus,
                unsigned char clipy1, unsigned char clipy2)
{
  unsigned char x, y;
  unsigned char h;
  unsigned char x1, y1, x2, y2;

  if(window->y + 1 >= clipy2) {
    return;
  }

  x = window->x;
  y = window->y + 1;

  if(focus & 2) {
    textcolor(1);
  } else {
    textcolor(1);
  }

  x1 = x + 1;
  y1 = y + 1;
  x2 = x1 + window->w;
  y2 = y1 + window->h;


  if(y >= clipy1) {
    cputcxy(x, y, '+');
    gotoxy(wherex() + window->titlelen + 2, wherey());
    chline(window->w - (wherex() - x) - 2);
    cputcxy(x2, y, '+');
  }

  h = window->h;

  if(clipy1 > y1) {
    if(clipy1 - y1 < h) {
      h = clipy1 - y1;
            y1 = clipy1;
    } else {
      h = 0;
    }
  }

  if(clipy2 < y1 + h) {
    if(y1 >= clipy2) {
      h = 0;
    } else {
      h = clipy2 - y1;
    }
  }

  cvlinexy(x, y1, h);
  cvlinexy(x2, y1, h);

  if(y + window->h >= clipy1 &&
     y + window->h < clipy2) {
    cputcxy(x, y2, '+');
    chlinexy(x1, y2, window->w);
    cputcxy(x2, y2, '+');
  }

  draw_window_contents(window, focus & 2, clipy1, clipy2,
                       x1, x2, y + 1, y2);
}

void
ctk_draw_dialog(struct ctk_window *dialog)
{
  unsigned char x, y;
  unsigned char i;
  unsigned char x1, y1, x2, y2;

  textcolor(1);

  x = dialog->x;
  y = dialog->y + 1;


  x1 = x + 1;
  y1 = y + 1;
  x2 = x1 + dialog->w;
  y2 = y1 + dialog->h;




  cvlinexy(x, y1,
           dialog->h);
  cvlinexy(x2, y1,
           dialog->h);

  chlinexy(x1, y,
           dialog->w);
  chlinexy(x1, y2,
           dialog->w);

  cputcxy(x, y, '+');
  cputcxy(x, y2, '+');
  cputcxy(x2, y, '+');
  cputcxy(x2, y2, '+');



  for(i = y1; i < y2; ++i) {
    cclearxy(x1, i, dialog->w);
  }

  draw_window_contents(dialog, 4, 0, sizey,
                       x1, x2, y1, y2);
}

void
ctk_draw_clear(unsigned char y1, unsigned char y2)
{
  unsigned char i;

  for(i = y1; i < y2; ++i) {
    cclearxy(0, i, sizex);
  }
}

static void
draw_menu(struct ctk_menu *m)
{
  unsigned char x, x2, y;
  textcolor(1);
  x = wherex();
  cputs(m->title);
  cputc(' ');
  x2 = wherex();
  if(x + 16 > sizex) {
    x = sizex - 16;
  }


  for(y = 0; y < m->nitems; ++y) {
    if(y == m->active) {
      textcolor(1);
      revers(0);
    } else {
      textcolor(1);
    }
    gotoxy(x, y + 1);
    if(m->items[y].title[0] == '-') {
      chline(16);
    } else {
      cputs(m->items[y].title);
    }
    if(x + 16 > wherex()) {
      cclear(x + 16 - wherex());
    }
    revers(1);
  }
  gotoxy(x2, 0);
  textcolor(1);
}

void
ctk_draw_menus(struct ctk_menus *menus)
{
  struct ctk_menu *m;


  textcolor(1);
  gotoxy(0, 0);
  revers(1);
  cputc(' ');
  for(m = menus->menus->next; m != 0; m = m->next) {
    if(m != menus->open) {
      cputs(m->title);
      cputc(' ');
    } else {
      draw_menu(m);
    }
  }


  if(wherex() + strlen(menus->desktopmenu->title) + 1>= sizex) {
    gotoxy(sizex - strlen(menus->desktopmenu->title) - 1, 0);
  } else {
    cclear(sizex - wherex() -
           strlen(menus->desktopmenu->title) - 1);
  }


  if(menus->desktopmenu != menus->open) {
    cputs(menus->desktopmenu->title);
    cputc(' ');
  } else {
    draw_menu(menus->desktopmenu);
  }

  revers(0);
}

unsigned char
ctk_draw_height(void)
{
  return sizey;
}

unsigned char
ctk_draw_width(void)
{
  return sizex;
}

Re: trouble with porting architecture

[Eric Botcazou]

> One common work around on that processor is to consider a few locations
> in page zero (first 256 bytes of memory) as fake 16-bit registers (one or
> two), since these locations are relatively cheap to load/store.

Thanks for the tip.  However, this won't work for any architectures based on
the MC6809: for example, on the Thomson architecture (old French computer
series), page 0 is mapped to the ROM cartridge :-)

--
Eric Botcazou

Re: trouble with porting architecture

[tm_gccmail]

On Tue, 30 Dec 2003, Eric Botcazou wrote:

> > One common work around on that processor is to consider a few locations
> > in page zero (first 256 bytes of memory) as fake 16-bit registers (one or
> > two), since these locations are relatively cheap to load/store.
> 
> Thanks for the tip.  However, this won't work for any architectures based on
> the MC6809: for example, on the Thomson architecture (old French computer
> series), page 0 is mapped to the ROM cartridge :-)
> 
> --
> Eric Botcazou

"Page zero" is an implementation artifact on the 6502 and derivatives
where addresses in the first 256 bytes can be accessed via a two-byte
instruction rather than a three-byte instruction.

This feature is specific to the 6502 and is not a generally supported
feature on 8-bit processors.

So using "page zero" only has an advantage on the 6502.

Toshi

Re: trouble with porting architecture

[Andrew Haley]

tm_gccmail@kloo.net writes:
 > On Tue, 30 Dec 2003, Eric Botcazou wrote:
 > 
 > > > One common work around on that processor is to consider a few locations
 > > > in page zero (first 256 bytes of memory) as fake 16-bit registers (one or
 > > > two), since these locations are relatively cheap to load/store.
 > > 
 > > Thanks for the tip.  However, this won't work for any architectures based on
 > > the MC6809: for example, on the Thomson architecture (old French computer
 > > series), page 0 is mapped to the ROM cartridge :-)
 > 
 > "Page zero" is an implementation artifact on the 6502 and derivatives
 > where addresses in the first 256 bytes can be accessed via a two-byte
 > instruction rather than a three-byte instruction.
 > 
 > This feature is specific to the 6502 and is not a generally supported
 > feature on 8-bit processors.
 > 
 > So using "page zero" only has an advantage on the 6502.

The same technique is still applicable on the 6809.  It's just that
page "zero" can be mapped to any page of memory by changing the DP
register.

Andrew.

Re: trouble with porting architecture

[Hans-Peter Nilsson]

On Tue, 30 Dec 2003 tm_gccmail@kloo.net wrote:
> "Page zero" is an implementation artifact on the 6502 and derivatives
> where addresses in the first 256 bytes can be accessed via a two-byte
> instruction rather than a three-byte instruction.
>
> This feature is specific to the 6502 and is not a generally supported
> feature on 8-bit processors.
>
> So using "page zero" only has an advantage on the 6502.

The 6809 *does* have a similar short addressing mode ("direct";
saving a whole byte) *and* the implied high byte "page" is a
settable register (DP); not necessarily zero, that is.

Not that short addressing modes are necessary for "faking"
registers, still facts are facts...

brgds, H-P
PS.  Wow, so many google hits for "6809 reference card"!

Re: trouble with porting architecture

[Eric Botcazou]

[-- Attachment #1: Type: text/plain, Size: 1230 bytes --]

> Hopefully this'll be of more help... sorry for the previous sparse and
> anemic report. :)

Thanks.  I could reproduce the problem with my GCC 2.95.3-based compiler.

> ../contiki/ctk/ctk-conio.c:510: unable to generate reloads for:
> (insn 99 98 100 (set (reg:QI 0 d [32])
>          (minus:QI (reg:QI 33)
>              (reg:QI 0 d [34]))) 31 {subqi3} (nil)
>      (expr_list:REG_DEAD (reg:QI 33)
>          (expr_list:REG_DEAD (reg:QI 0 d [34])
>              (nil))))
> ../contiki/ctk/ctk-conio.c:510: Internal compiler error in
> find_reloads, at reload.c:3576
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.

I was wrong: the insn is problematic because it's

  op0 = op1 - op0

and not

  op0 = op0 - op1.


The MC6809 back-end appears to use a "looseness" strategy to avoid generating 
lots of memory references during RTL expansion and to expect that reload 
will fix up everything at the end.  This doesn't work here because the 
subqi3 pattern is not commutative.

The attached patch restores the symmetry, but it was not tested except on 
your testcase (the code looks correct at -O0, -O1, -O2).

-- 
Eric Botcazou

[-- Attachment #2: m6809_subqi3.diff --]
[-- Type: text/x-diff, Size: 1104 bytes --]

--- m6809.md	2001/12/13 02:30:08	1.1
+++ m6809.md	2004/01/07 18:31:06
@@ -763,16 +763,25 @@
 ;;-}")
     
 (define_insn "subqi3"
-  [(set (match_operand:QI 0 "register_operand" "=q")
-	(minus:QI (match_operand:QI 1 "register_operand" "0")
-		  (match_operand:QI 2 "address_operand" "min")))]
+  [(set (match_operand:QI 0 "register_operand" "=q,!q")
+	(minus:QI (match_operand:QI 1 "address_operand" "0,min")
+		  (match_operand:QI 2 "address_operand" "min,0")))]
   ""
   "*
 {
-    if (operands[2] == const1_rtx)
-	return \"dec%0\\t\\t;subhi: R:%0 -= 1\";
-    else
-      return \"sub%0\\t%2\\t;subhi: R:%0 -= %2\";
+    if (which_alternative == 0) {
+	if (operands[2] == const1_rtx)
+	    return \"dec%0\\t\\t;subqi: R:%0 -= 1\";
+	else
+	    return \"sub%0\\t%2\\t;subqi: R:%0 -= %2\";
+    }
+    else {
+	if (operands[1] == const1_rtx)
+	    output_asm_insn(\"dec%0\\t\\t;subqi: R:%0 = 1 - R:%0\", operands);
+	else
+	    output_asm_insn(\"sub%0\\t%1\\t;subqi: R:%0 = %1 - R:%0\", operands);
+	return \"neg%0\";
+    }
 }")
 
 ;;--------------------------------------------------------------------

Adding soft-registers (was: trouble with porting architecture)

[James Dessart]

On 7-Jan-04, at 1:51 PM, Eric Botcazou wrote:

> The MC6809 back-end appears to use a "looseness" strategy to avoid 
> generating
> lots of memory references during RTL expansion and to expect that 
> reload
> will fix up everything at the end.  This doesn't work here because the
> subqi3 pattern is not commutative.

Thanks!  This seems to fix up the problem with the compiler.  I'll run 
it through its paces when I get a chance.

What I would like to do, though, is add some soft registers to the 
port.  Others are interested in using the port for floating point, with 
soft floating point support, but none of us have the knowledge to add 
the required extra registers.  I tried reading the gccint documents, 
but they're really just a reference to what's there.  I tried using the 
mc68hc11 port (which has soft registers) to see how to do it, but I got 
lost between the piles of related macros, the C implementation and the 
machine description.  Is there a howto somewhere?

Thanks,
James

Re: Adding soft-registers

[Stephane Carrez]

Hi!

James Dessart wrote:
> 
> On 7-Jan-04, at 1:51 PM, Eric Botcazou wrote:
> 
>> The MC6809 back-end appears to use a "looseness" strategy to avoid 
>> generating
>> lots of memory references during RTL expansion and to expect that reload
>> will fix up everything at the end.  This doesn't work here because the
>> subqi3 pattern is not commutative.
> 
> 
> Thanks!  This seems to fix up the problem with the compiler.  I'll run 
> it through its paces when I get a chance.
> 
> What I would like to do, though, is add some soft registers to the 
> port.  Others are interested in using the port for floating point, with 
> soft floating point support, but none of us have the knowledge to add 
> the required extra registers.  I tried reading the gccint documents, but 
> they're really just a reference to what's there.  I tried using the 
> mc68hc11 port (which has soft registers) to see how to do it, but I got 
> lost between the piles of related macros, the C implementation and the 
> machine description.  Is there a howto somewhere?
> 
> Thanks,
> James

FYI the 6809 is intermediate between 68HC11 and 68HC12: same regs,
same instruction set, same addressing modes as HC11 + restricted auto increment
mode (restricted compared to HC12).  My feeling is that you should
be able to steal the hole hc11 port and hack it to your needs (and pretend
it is an HC12 as the 6809 is closer to it then to HC11; except for movXXX patterns:-) ).

I don't have a document that explains the particular implementation of m68hc11
port.  Check http://stephane.carrez.free.fr/doc/hc11_3.html#SEC17 to see
how the soft regs are mapped and .... use the source James...

What is important for such soft reg is that they are in memory and as such
you have to be careful when you define your constraints.  The movXXX must be
defined with care because you don't have a memory <-> memory move.

	Stephane

-- 
         Home                           Office
E-mail: stcarrez@nerim.fr              Stephane.Carrez@solsoft.com
WWW:    http://stcarrez.nerim.net      http://www.solsoft.com
         Free the Software!             Security Policy Management

Re: Adding soft-registers

[James Dessart]

On Thu, 8 Jan 2004, Stephane Carrez wrote:

> FYI the 6809 is intermediate between 68HC11 and 68HC12: same regs,
> same instruction set, same addressing modes as HC11 + restricted auto increment
> mode (restricted compared to HC12).  My feeling is that you should
> be able to steal the hole hc11 port and hack it to your needs (and pretend
> it is an HC12 as the 6809 is closer to it then to HC11; except for movXXX patterns:-) ).

There is a difference, a rather big one, in the direct mode.  The HC11 and
HC12s only address page 0.  The 6809 has a register to configure which 256
byte page that the direct mode points at.  As a result, two machines which
I know of that use the 6809 (the TRS-80 Color Computer series and the
Thomson series from France) both have content in page 0 in a normal
configuration, that the application may want to access.

So the page 0 implementation that those ports use is limited.  What would
be nice is a run-time configured page that contains the registers.  The
direct page register could be configured in the runtime, and the compiled
code wouldn't know the difference.  The problem is that the segment that
would be used would need to be on a page boundary... I'm not sure the
assembler or linker are properly set up to do that sort of thing in a
memory-efficient way.  What do you think, Eric?  Other than me, you're
probably the one who's played with those tools the most, and perhaps the
author. :)

James

Re: Adding soft-registers

[tm_gccmail]

On Thu, 8 Jan 2004, James Dessart wrote:

> 
> 
> On Thu, 8 Jan 2004, Stephane Carrez wrote:
> 
> > FYI the 6809 is intermediate between 68HC11 and 68HC12: same regs,
> > same instruction set, same addressing modes as HC11 + restricted auto increment
> > mode (restricted compared to HC12).  My feeling is that you should
> > be able to steal the hole hc11 port and hack it to your needs (and pretend
> > it is an HC12 as the 6809 is closer to it then to HC11; except for movXXX patterns:-) ).
> 
> There is a difference, a rather big one, in the direct mode.  The HC11 and
> HC12s only address page 0.  The 6809 has a register to configure which 256
> byte page that the direct mode points at.  As a result, two machines which
> I know of that use the 6809 (the TRS-80 Color Computer series and the
> Thomson series from France) both have content in page 0 in a normal
> configuration, that the application may want to access.
> 
> So the page 0 implementation that those ports use is limited.  What would
> be nice is a run-time configured page that contains the registers.  The
> direct page register could be configured in the runtime, and the compiled
> code wouldn't know the difference.  The problem is that the segment that
> would be used would need to be on a page boundary... I'm not sure the
> assembler or linker are properly set up to do that sort of thing in a
> memory-efficient way.  What do you think, Eric?  Other than me, you're
> probably the one who's played with those tools the most, and perhaps the
> author. :)
> 
> James

It sounds like the 6809 direct page differs from the 65816 direct page
because the 65816 direct page is settable on a byte boundary. This allowed
it be used as the frame pointer, and we generally accessed the locals on
the stack via the direct page.

It sounds like, in your case, you will need to use an indexed absolute
addressing mode to access your soft registers.

Toshi

Re: Adding soft-registers

[Stephane Carrez]

James Dessart wrote:
> 
> On Thu, 8 Jan 2004, Stephane Carrez wrote:
> 
> 
>>FYI the 6809 is intermediate between 68HC11 and 68HC12: same regs,
>>same instruction set, same addressing modes as HC11 + restricted auto increment
>>mode (restricted compared to HC12).  My feeling is that you should
>>be able to steal the hole hc11 port and hack it to your needs (and pretend
>>it is an HC12 as the 6809 is closer to it then to HC11; except for movXXX patterns:-) ).
> 
> 
> There is a difference, a rather big one, in the direct mode.  The HC11 and
> HC12s only address page 0.  The 6809 has a register to configure which 256
> byte page that the direct mode points at.  As a result, two machines which
> I know of that use the 6809 (the TRS-80 Color Computer series and the
> Thomson series from France) both have content in page 0 in a normal
> configuration, that the application may want to access.

As far as gcc is concerned, this is minor.  This does not affect the code
generation.  The difference in addressing modes and difference of instruction
set is more important as the 6809 is between the two (you must disable the tbcc
and dbcc insn for example).

> 
> So the page 0 implementation that those ports use is limited.  What would
> be nice is a run-time configured page that contains the registers.  The
> direct page register could be configured in the runtime, and the compiled
> code wouldn't know the difference.  The problem is that the segment that
> would be used would need to be on a page boundary... I'm not sure the
> assembler or linker are properly set up to do that sort of thing in a
> memory-efficient way.  What do you think, Eric?  Other than me, you're
> probably the one who's played with those tools the most, and perhaps the
> author. :)
> 
> James

This can be done by the linker script.  You should specify a region that
you map wherever you want on 256b boundary.  Your registers/direct addressing
global variables should be put in a section that is mapped to that region.

You can even manage to make the linker perform linker relaxation and transform
any 16-bit extended addressing into direct page addressing.  The hc11 linker
performs that.  This is triggered for [0..0xff] addresses but could be changed
for whatever page.

	Stephane

-- 
         Home                           Office
E-mail: stcarrez@nerim.fr              Stephane.Carrez@solsoft.com
WWW:    http://stcarrez.nerim.net      http://www.solsoft.com
         Free the Software!             Security Policy Management

Re: Adding soft-registers

[Stephane Carrez]

tm_gccmail@kloo.net wrote:
> 
> It sounds like the 6809 direct page differs from the 65816 direct page
> because the 65816 direct page is settable on a byte boundary. This allowed
> it be used as the frame pointer, and we generally accessed the locals on
> the stack via the direct page.
> 

Interesting!  It must be changed to a 16-bit register then does it?
If you have this your task is easier in gcc because you don't fall in the
reload nightmare (or reduce it).

	Stephane

-- 
         Home                           Office
E-mail: stcarrez@nerim.fr              Stephane.Carrez@solsoft.com
WWW:    http://stcarrez.nerim.net      http://www.solsoft.com
         Free the Software!             Security Policy Management

Re: Adding soft-registers

[tm_gccmail]

On Thu, 8 Jan 2004, Stephane Carrez wrote:

> 
> 
> tm_gccmail@kloo.net wrote:
> > 
> > It sounds like the 6809 direct page differs from the 65816 direct page
> > because the 65816 direct page is settable on a byte boundary. This allowed
> > it be used as the frame pointer, and we generally accessed the locals on
> > the stack via the direct page.
> > 
> 
> Interesting!  It must be changed to a 16-bit register then does it?
> If you have this your task is easier in gcc because you don't fall in the
> reload nightmare (or reduce it).
> 
> 	Stephane

Yes, the DP and SP registers are 16 bits on the 65816.

The 65816 address space, however, is 24 bits, so the stack is limited
to the first 64k. This wasn't too terrible a restriction as long
as people didn't try to alloca() large amounts of memory.

Toshi

Re: Adding soft-registers

[James Dessart]

On 8-Jan-04, at 4:56 PM, Stephane Carrez wrote:

> This can be done by the linker script.  You should specify a region 
> that
> you map wherever you want on 256b boundary.  Your registers/direct 
> addressing
> global variables should be put in a section that is mapped to that 
> region.

Actually, it appears that the assembler/linker pair support that 
already.  Wunderbar! :) So it'll be pretty straightforward to take the 
68hc1x code and bring it over.

James

Re: Adding soft-registers

[Eric Botcazou]

> There is a difference, a rather big one, in the direct mode.  The HC11 and
> HC12s only address page 0.  The 6809 has a register to configure which 256
> byte page that the direct mode points at.

I agree with Stephane that this is not signicant from GCC viewpoint.

> So the page 0 implementation that those ports use is limited.  What would
> be nice is a run-time configured page that contains the registers.  The
> direct page register could be configured in the runtime, and the compiled
> code wouldn't know the difference.  The problem is that the segment that
> would be used would need to be on a page boundary... I'm not sure the
> assembler or linker are properly set up to do that sort of thing in a
> memory-efficient way.  What do you think, Eric?

Nothing worth mentioning.  I have never really investigated playing with the 
DP register.

> Other than me, you're probably the one who's played with those tools the
> most, and perhaps the author. :)

Not that much.  And by that time, I was new to GCC so I was already very 
happy to have sort of a working compiler :-)

I think that, if you want to enhance the 6809 port, you should consider 
switching to the HC11/HC12 back-end, instead of trying to re-implement 
similar constructs.  It is much more complete and up-to-date.  And you could 
still ask your questions in French :-)

-- 
Eric Botcazou