[M16C-dev] Binutils + GCC port

[Dr. Manuel Kessler]

Hello all,

unfortunately I did not manage to fill in my modifications in CVS last
Tuesday, however, it is done by now. Moreover, as a bonus I have solved a
long standing problem, namely not being able to generate the correct size
of displacements. In fact, for many months I only had the option to
generate either
- the correct size for fixed values, but at the price of only 8 bit
  displacements for relocations (unusable), or
- generally 24 bit displacements, even if it is only a fixed 1(one)
  (wasteful)
The solution was to allow relaxable instructions in
m16c_cgen_assemble_insn, and cancel them later only if there had been a
fixup generated. While this might not be optimal, it seems to work up to
now. Furthermore, the linker does its job as well, at least for 8 and 16
bit displacements. 24 bit do not work yet, probably due to crossing a 32
bit boundary for these instructions.

While the transition from binutils 2.13 to 2.13.1 and 2.13.2.1 went
smoothly, I am struggling a little bit with the update to 2.14, but it is
on the road.

Regarding the comments for the appropriateness of GCC for a port to M16C,
I see several options:
- Abandon GCC, and move to another free compiler, as suggested (LCC, SDCC,
  VBCC). This would not only loose other front ends (where C++ is the main
  reason I am doing this port anyway), but also the sophisticated higher
  level optimisations available in GCC. Without disrespect for the others,
  I am quite sure that these are not that much sophisticated as GCC is.
  However, these two drawbacks may or may not apply to your envisioned
  application.
- Support some kind of a HUGE model only, a TINY model only, or both of
  them, depending on some command line switch (or maybe even at GCC
  compile time). This would be either a severe restriction (TINY) or a
  waste (HUGE). In the latter case, the problem is not that hard as
  described by Grant (little or no instructions), as pointers can be kept
  in A0/A1, and some arithmetic is possible in there (e.g. pointer
  increment) with the appropriate size. Anyway, all pointers are the same
  size in this case.
- Enhance GCC to support different pointer sizes, and mark all function
  pointers (and possibly void * ?) as far (or FAR, LARGE, whatever). The
  correspondance between function and data pointers is seldom used anyway
  and could be achieved in the necessary cases via an __attribute__,
  inline assembly or some similar mechanism. I am not sure how much effort
  this means, or if it is mostly there already.
- Keep all pointers at 24 bit (i.e. HUGE model), but use only the lower 16
  bit for data access in the opcode generation stage. This might be an
  interim solution.

Speaking for myself, I do not like option #1 and am in favor of #3,
provided we do not have to completely rewrite GCC. Otherwise I would
prefer #4, which sounds as a reasonable compromise.

While binutils does not have to be finished to start the port, at least
some assembler seems striclty needed. Is there any available besides the
one by Mitsubishi/Renesas under Win**ws? If yes, feel free to start. Any
takers?

Ciao,
        Manuel

______________________________________________________________________

Dr. Manuel Kessler, Dipl.-Phys.

Institut fuer Aerodynamik und Gasdynamik
Universitaet Stuttgart
Pfaffenwaldring 21           ( ( ( ( ___________.^.___________ ) ) ) )
70550 Stuttgart / Germany                      _\I/_
                                              /\_|_/\
Phone:      +49 711 685 3419                  \_(_)_/
Fax:        +49 711 685 3438                 ./     \.
E-Mail:     address@hidden
WWW:        http://www.iag.uni-stuttgart.de/people/manuel.kessler
______________________________________________________________________