Grant Edwards <grante@visi.com> writes:> I see from your page that GCC supports 1M of code space on the M16C, > yet has 16 bit pointers. How are pointers to functions handled?Thunks. For each function needing a 16 bit pointer, a jump opcode is placed in the 16 bit address space which jumps to the function, and the address of that opcode is used.
Renesas HEW
Started by ●May 9, 2006
Reply by ●May 9, 20062006-05-09
Reply by ●May 9, 20062006-05-09
On 2006-05-09, DJ Delorie <dj@delorie.com> wrote:> > Grant Edwards <grante@visi.com> writes: >> I see from your page that GCC supports 1M of code space on the M16C, >> yet has 16 bit pointers. How are pointers to functions handled? > > Thunks.You're wulcome.> For each function needing a 16 bit pointer, a jump opcode is > placed in the 16 bit address space which jumps to the > function, and the address of that opcode is used.Thanks. I'll add the Mitsubishi parts to the "preferred" list now that there are gnu tools for them. :) -- Grant Edwards grante Yow! Is it FUN to be at a MIDGET? visi.com
Reply by ●May 9, 20062006-05-09
Grant Edwards <grante@visi.com> writes:> I'll add the Mitsubishi parts to the "preferred" list now that > there are gnu tools for them. :)FYI: Mitsubishi sold that line to Renesas, so they're now Renesas parts.
Reply by ●May 9, 20062006-05-09
On 2006-05-10, DJ Delorie <dj@delorie.com> wrote:> > Grant Edwards <grante@visi.com> writes: >> I'll add the Mitsubishi parts to the "preferred" list now that >> there are gnu tools for them. :) > > FYI: Mitsubishi sold that line to Renesas, so they're now Renesas > parts.Sort of. The microprocessor divisions of Hitachi and Mitsubishi merged and formed Renesas. However, I still refer to the M16C et al as Mitsubishi processors and H8 et al as Hitachi processors. AFAICT, they've put the "Renesas" name on everything, but the old Hitachi and Mitsubishi organizations are still pretty much separate. -- Grant Edwards
Reply by ●May 9, 20062006-05-09
Grant Edwards <grante@visi.com> writes:> AFAICT, they've put the "Renesas" name on everything, but the old > Hitachi and Mitsubishi organizations are still pretty much separate.I don't think I've ever seen a corporate merger go as smoothly as hoped, but in this case, there's at least one reason to start thinking of them as "Renesas" - that's what you have to search for at digikey to find their chips ;-)
Reply by ●May 10, 20062006-05-10
On 09 May 2006 15:53:43 -0400, DJ Delorie <dj@delorie.com> wrote:> >"Henrik [6650]" <not@valid.com> writes: >> However, if better tools where around (they might be, I have not >> checked) I would still recommend the chips. They are quite cool and >> very cheap. > >I recently finished porting gcc and binutils to the r8c/m16c/m32c >families, and gdb support was recently added too (with a simulator).Where are the differences between your port an KPIT's one ? -- 42Bastian Do not email to bastian42@yahoo.com, it's a spam-only account :-) Use <same-name>@monlynx.de instead !
Reply by ●May 10, 20062006-05-10
On 09 May 2006 15:53:43 -0400, DJ Delorie <dj@delorie.com> wrote:>I recently finished porting gcc and binutils to the r8c/m16c/m32c >families, and gdb support was recently added too (with a simulator). > >My notes are here: http://people.redhat.com/dj/m32c/Where can I find the calling convention used ? (W/o digging the gcc sources :-) -- 42Bastian Do not email to bastian42@yahoo.com, it's a spam-only account :-) Use <same-name>@monlynx.de instead !
Reply by ●May 10, 20062006-05-10
bastian42@yahoo.com (42Bastian Schick) writes:> Where are the differences between your port an KPIT's one ?I'm the m32c gcc and binutils maintainer, which means I'm putting in most of the work to the FSF's sources. I don't know if KPIT changes anything, but in general, they're just taking the FSF's gcc sources, building them, and packaging them up. They've submitted a couple of patches to gcc that I've rejected as incorrect, which indicates that they might have different sources than the official ones. You'd have to check their release notes to know for sure. Other than that, new stuff tends to show up in the FSF sources first, followed by the KPIT release as soon as they get around to rebuilding it. Also, since KPIT takes a snapshot and (I assume) tests it, you're less likely to be bitten by "current development" breaking something. Although, if you do get bitten, I *really* want to know about it ;-)
Reply by ●May 10, 20062006-05-10
bastian42@yahoo.com (42Bastian Schick) writes:> Where can I find the calling convention used ? > (W/o digging the gcc sources :-)Here is gcc/config/m32c/m32c.abi from the gcc sources. The only major difference is that gcc has 16 bytes of "memory" registers, mem0..mem15, which it uses as additional real registers. GCC doesn't like chips with small numbers of registers, I've found I get better code sometimes if it has some spare (albeit costly) registers to use. You can disable those with command line options if you don't need them, but you'll have to rebuild libgcc.a if you do. Reducing the dependency on these spare registers is a to-do item. Target Definitions for R8C/M16C/M32C Copyright (C) 2005 Free Software Foundation, Inc. Contributed by Red Hat. This file is part of GCC. GCC is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version. GCC is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with GCC; see the file COPYING. If not, write to the Free Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. These are just some random notes I used during development of this port. Please don't consider these to be "official" specifications, just additional information to help make the code easier to understand. Frame ===== +-------------------- | incoming args +-------------------- | return Address osp -> +-------------------- | saved fp fp -> +-------------------- | local data +-------------------- | saved regs +-------------------- | outgoing args (opt) sp -> +-------------------- Argument Passing ================ r8c, m16c --------- First arg may be passed in r1l or r1 if it (1) fits (QImode or HImode), (2) is named, and (3) is an integer or pointer type (no structs, floats, etc). Otherwise, it's passed on the stack. Second arg may be passed in r2, same restrictions (but not QImode), even if the first arg is passed on the stack. Third and further args are passed on the stack. No padding is used, stack "alignment" is 8 bits. m32cm, m32c ----------- First arg may be passed in r0l or r0, same restrictions as above. Second and further args are passed on the stack. Padding is used after QImode parameters (i.e. lower-addressed byte is the value, higher-addressed byte is the padding), stack "alignment" is 16 bits. Return Value ============ r8c, m16c --------- QImode in r0l HImode in r0 near pointer in r0 (desired) SImode in r2r0 far pointer in r2r0 (actual) Anything bigger than 16 bits is returned in memory, at mem0 (mem0 through mem15 are provided by libgcc.a) Aggregate values (regardless of size) are returned by pushing a pointer to a temporary area on the stack after the args are pushed. The function fills in this area with the value. Note that this pointer on the stack does not affect how register arguments, if any, are configured. m32cm, m32c ----------- Same. Registers Preserved Across Calls ================================ r8c, m16c --------- sb, fb, sp (i.e. nearly all registers are call clobbered) m32cm, m32c ----------- r1, r2, r3, a0, a1, sb, fb, sp (except when used for return values) Interrupt Handlers ================== The stack frame is slightly different for interrupt handlers, because (1) we don't have a usable parent frame, and (2) we have to use special instructions to return and thus must save/restore everything differently. +-------------------- | program state osp -> +-------------------- | return address +-------------------- | saved r0..fp (pushm) fp -> +-------------------- | local data +-------------------- | saved regs mem0..mem15 +-------------------- | outgoing args (opt) sp -> +--------------------
Reply by ●May 11, 20062006-05-11
On 10 May 2006 10:27:43 -0400, DJ Delorie <dj@delorie.com> wrote:> >bastian42@yahoo.com (42Bastian Schick) writes: >> Where can I find the calling convention used ? >> (W/o digging the gcc sources :-) > >Here is gcc/config/m32c/m32c.abi from the gcc sources. The only majorThanks. -- 42Bastian Do not email to bastian42@yahoo.com, it's a spam-only account :-) Use <same-name>@monlynx.de instead !
