[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[M16C-dev] Binutils + GCC port
From: |
Dr. Manuel Kessler |
Subject: |
[M16C-dev] Binutils + GCC port |
Date: |
Wed, 5 Nov 2003 16:25:28 +0100 (CET) |
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
______________________________________________________________________
- [M16C-dev] Binutils + GCC port,
Dr. Manuel Kessler <=