Hi Paul,

> >You may find lot of useful documents on www.kpitgnutools.com like
> >compiler, Assembler manuals, migration guides for users who want to
>
> I found other sources more useful.

Kindly let us know the document sources you are referring too.
This will help us to improve the documentation on kpitgnutools website.

> >migrate from proprietary compiler to GNU compiler. More importantly,
> >you can get ABI descriptions for all GNU tool chains targeted for
> >Renesas SH, H8/300 and R8C, M16C, M32C families of processors.
> >Simply, click on "Documentation" -> "User Manuals" and choose the
> >document you want to read.
>
> Hmm ABI specs came originally from elsewhere, the manuals in my view
> are sparse (Renesas ones as well).

The advantage of this is programmer can refer to ABI of all Renesas
target GNU compilers at one place.

Regards,
Anil Paranjpe

On 21 May, in article
     <1148271439.661082.20880@i40g2000cwc.googlegroups.com>
     anilp1@kpitcummins.com "Anil" wrote:
>Hi,
>
>>>> 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.
>
>As you rightly said, we take latest, stable source snapshot from FSF,
>build the tool chain and package the installer so as to run on Windows
>as well as Linux.
>We release KPIT GNU tool chains every four months i.e. 3 release a
>year.
>All KPIT GNU tool chains get automatically integrated into Renesas HEW
>IDE.

That is a waste of time incorporating into HEW, having spent some time with
it now, it is only useful for throw away apps that do not require maintenence
for more than 2 months. HEW seems targetted at PC applications developers
toying with embedded, too many files get incorporated that are not needed,
the linker script gets embedded into HEW specific files. Changing toolchain
is not possible without recreating a 'workspace', there is special commands
to change toolchain version!

Persoanlly if it had a simpler version that allowed easier debug/simulator
only without loads of unnecessary wizards, it might be worthwhile.

The fact that the look and feel is almost identical to FDT (for flashing
devices) is too much of a recipe for trouble. The interface methods on
both apps are too clunky and full of wizards and lots of mouse clicks.
Nothing is logically laid out, all debug functions under one LONG menu.

Only one workspace file of ANY name in one directory and inability to easily
duplicate one workspace to become another workspace (or template) using
same or different toolchain is painful.

Overall it is too much work for what it is trying to achieve. Makes
documentation and maintenance of any project that has to be maintained
for a year or more nearly imposible. Current projects may well have to be
supported for 10 years or more.

....
>You may find lot of useful documents on www.kpitgnutools.com like
>compiler, Assembler manuals, migration guides for users who want to

I found other sources more useful.

>migrate from proprietary compiler to GNU compiler. More importantly,
>you can get ABI descriptions for all GNU tool chains targeted for
>Renesas SH, H8/300 and R8C, M16C, M32C families of processors.
>Simply, click on "Documentation" -> "User Manuals" and choose the
>document you want to read.

Hmm ABI specs came originally from elsewhere, the manuals in my view
are sparse (Renesas ones as well).

-- 
Paul Carpenter          | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/>    PC Services
<http://www.gnuh8.org.uk/>              GNU H8 & mailing list info
<http://www.badweb.org.uk/>             For those web sites you hate

Hi,

>>> 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.

As you rightly said, we take latest, stable source snapshot from FSF,
build the tool chain and package the installer so as to run on Windows
as well as Linux.
We release KPIT GNU tool chains every four months i.e. 3 release a
year.
All KPIT GNU tool chains get automatically integrated into Renesas HEW
IDE.

>>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.

We will be posting modified patches after incorporating your comments
into it.
We will also be posting couple of problems we found in existing
patches.

>>You'd have to check their release notes to know for sure.
We mention the source versions, known problems and new enhancement or
information about bug fixes in the release notes of KPIT GNU tool
chain.

>>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 ;-)

Though we take latest stable snapshot or released version of source, we
are not completely dependent on regression results of that source. We
have our own set of test cases written to test the compiler, libraries.
We also have our own test Suite to test DWARF2 output generated i.e.
debugging capacity of compiler.
Moreover, we also test all samples on actual Renesas hardware kits in
release as well as debug mode, with and without optimization enabled.
We publish whatever problems we found in testing and could not be fixed
in specified Time, in Release notes. If we have any workaround for
same, we write that too.

You may find lot of useful documents on www.kpitgnutools.com like
compiler, Assembler manuals, migration guides for users who want to
migrate from proprietary compiler to GNU compiler. More importantly,
you can get ABI descriptions for all GNU tool chains targeted for
Renesas SH, H8/300 and R8C, M16C, M32C families of processors.
Simply, click on "Documentation" -> "User Manuals" and choose the
document you want to read.

Regards,
Anil Paranjpe

Hi,

>>> 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.

As you rightly said, we take latest, stable source snapshot from FSF,
build the tool chain and package the installer so as to run on Windows
as well as Linux.
We release KPIT GNU tool chains every four months i.e. 3 release a
year.
All KPIT GNU tool chains get automatically integrated into Renesas HEW
IDE.

>>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.

We will be posting modified patches after incorporating your comments
into it.
We will also be posting couple of problems we found in existing
patches.

>>You'd have to check their release notes to know for sure.
We mention the source versions, known problems and new enhancement or
information about bug fixes in the release notes of KPIT GNU tool
chain.

>>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 ;-)

Though we take latest stable snapshot or released version of source, we
are not completely dependent on regression results of that source. We
have our own set of test cases written to test the compiler, libraries.
We also have our own test Suite to test DWARF2 output generated i.e.
debugging capacity of compiler.
Moreover, we also test all samples on actual Renesas hardware kits in
release as well as debug mode, with and without optimization enabled.
We publish whatever problems we found in testing and could not be fixed
in specified Time, in Release notes. If we have any workaround for
same, we write that too.

You may find lot of useful documents on www.kpitgnutools.com like
compiler, Assembler manuals, migration guides for users who want to
migrate from proprietary compiler to GNU compiler. More importantly,
you can get ABI descriptions for all GNU tool chains targeted for
Renesas SH, H8/300 and R8C, M16C, M32C families of processors.
Simply, click on "Documentation" -> "User Manuals" and choose the
document you want to read.

Regards,
Anil Paranjpe

On 2006-05-11, 42Bastian Schick <bastian42@yahoo.com> wrote:
> On 10 May 2006 10:23:56 -0400, DJ Delorie <dj@delorie.com> wrote:
>
>>
>>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.  
>
> Ah, good, I normaly stick to the FSFs sources for the targets I need
> the gcc, so I will as well for the m32c.

For the H8 target, I've found that the KPIT sources are often
ahead of the FSF sources.  KPIT appears to have been pretty
active in improving the H8 support in gcc, and a lot of
fixes/improvements show up in their packages before they make
it into the "official" tree.  It doesn't sound like they're as
active with the Mistubishi targets.

-- 
Grant Edwards                   grante             Yow!  I want DUSTIN
                                  at               HOFFMAN!! ... I want
                               visi.com            LIBRACE!! YOW!!

On 10 May 2006 10:23:56 -0400, DJ Delorie <dj@delorie.com> wrote:

>
>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.  

Ah, good, I normaly stick to the FSFs sources for the targets I need
the gcc, so I will as well for the m32c.

Thanks for clearing this.

BTW: Thanks for djgpp, it made DOS programming a lot more fun in the
old days :-)

-- 
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
Use <same-name>@monlynx.de instead !

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 major

Thanks.


-- 
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
Use <same-name>@monlynx.de instead !

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 ->	+--------------------

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 ;-)