NEC 78400 (78K.IV)

NEC 78400 (78K.IV)

[Jan Nieuwenhuizen]

Hi,

I'm looking for a free compiler for the NEC 78400 16bit embedded cpu,
does/will egcs support this (these kind of) processors, or do you know
of another compiler that does?  How much work is it to add support for 
a new processor?

Greetings,

Jan.

PS: I'm not subscribed to this list

Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.xs4all.nl/~jantien/lilypond

Re: NEC 78400 (78K.IV)

[Hans-Peter Nilsson]

> From: Jan Nieuwenhuizen <jantien@xs4all.nl>
> Date: Sun Oct 11 10:36:46 CEST 1998

> I'm looking for a free compiler for the NEC 78400 16bit embedded cpu,
> does/will egcs support this (these kind of) processors, or do
> you know
> of another compiler that does?  How much work is it to add
> support for a new processor?

I don't know this processor, and I do not see support in egcs
for an architecture by that name.

 Historically, it has been a bit of a hassle to port GCC to
generate code for a less-than-32-bit target system.
 However, there are a few 16-bit ports (judging from the
BITS_PER_WORD and POINTER_SIZE macros), for example to the
pdp11, 1750a and dsp16xx series, so it looks doable, modulo
strangeness in your architecture, such as memory segmenting.

 If you think porting GCC to this processor would be an
interesting task, you may find my master's thesis of some help,
besides the gcc.info pages.  See
<URL: ftp://ftp.axis.se/pub/axis/tools/cris/misc/rapport.ps >
(.pdf also available, .gz variants too).

 Don't forget that you need the other parts of a compiler-kit;
assembler, linker, library, whatnot.

Eh, how much work?  Let's say a couple of months for starters;
it "depends".

brgds, H-P
-- 
Hans-Peter Nilsson, Axis Communications AB, S - 223 70 LUND, SWEDEN
Hans-Peter.Nilsson@axis.se | Tel +46 462701867,2701800
Fax +46 46136130 | RFC 1855 compliance implemented; report loss of brain.

Re: NEC 78400 (78K.IV)

[Jeffrey A Law]

  In message < 199810111918.VAA03751@ignucius.axis.se >you write:
  >  Historically, it has been a bit of a hassle to port GCC to
  > generate code for a less-than-32-bit target system.
Pre-history.  GCC has been dealling with 16bit machines for a while
now.  The h8 and mn102 are still active (unlike the pdp11, 1750a and dsp16xx).

Usually the biggest problem with supporting 16bit ports is a lack of registers,
segmented addresses, and 16bit targets with 24bit addresses.

  > Eh, how much work?  Let's say a couple of months for starters;
  > it "depends".
It "depends" is about as precise as anyone can get :-)  The closer any new
chip resembles an existing port the faster one can get a port going.

Probably the simplest port I did took a month to get it up and functional
from the compiler's standpoint.  Others have taken many months.

jeff

Re: [Offtopic:] Status of 1750a port (Was Re: NEC 78400 (78K.IV))

[Jeffrey A Law]

  In message < 199810122247.AAA13360@ignucius.axis.se >you write:
  > Sidenote:
  >  Presumably the ESA (European Space Agency) think the 1750a
  > port is still active, but it looks like it's under local
  > maintenance, using gcc-2.7.2 as a base.
  >  Enter "1750" in the search box at <URL: http://www.esa.int/ > or just
  > <URL: http://www.estec.esa.nl/wmwww/WME/compilrs/Ch2_Description.html >.
  > 
  >  Hmm, maybe the local maintainers, "Chris Nettleton Software"
  > would be interested in cooperating with egcs?
  > (Or are they already here?)
I haven't seen any activity on the 1750a port, so I'd assumed it was dead.

I stand corrected.

jeff

[Offtopic:] Status of 1750a port (Was Re: NEC 78400 (78K.IV))

[Hans-Peter Nilsson]

> Date: Mon, 12 Oct 1998 14:22:59 -0600
> From: Jeffrey A Law <law@cygnus.com>

>   In message < 199810111918.VAA03751@ignucius.axis.se >you write:
>   >  Historically, it has been a bit of a hassle to port GCC to
>   > generate code for a less-than-32-bit target system.
> Pre-history.  GCC has been dealling with 16bit machines for a while
> now.  The h8 and mn102 are still active (unlike the pdp11, 1750a and dsp16xx).

Sidenote:
 Presumably the ESA (European Space Agency) think the 1750a
port is still active, but it looks like it's under local
maintenance, using gcc-2.7.2 as a base.
 Enter "1750" in the search box at <URL: http://www.esa.int/ > or just
<URL: http://www.estec.esa.nl/wmwww/WME/compilrs/Ch2_Description.html >.

 Hmm, maybe the local maintainers, "Chris Nettleton Software"
would be interested in cooperating with egcs?
(Or are they already here?)

brgds, H-P

[Offtopic:] Last status of 1750a port (Was Re: NEC 78400 (78K.IV))

[Hans-Peter Nilsson]

One more piece on this target, before it gets back to rest.
 Summary of an email-dialog with Chris Nettleton
(I introduced myself as a self-proclaimed messenger, so
summarizing should be OK):
 The "m1750" as they call their target, is certainly *based* on
the "1750a" target, but now renamed to coexist with the
inactive 1750a -- so you *were* right Jeff, and I shouldn't be
such a nitpick ;-)

The information at the ESA URL is outdated; the target
(version 1.1) is now branched from gcc-2.8.1.  There are no
immediate plans for merging or working with egcs or gcc2, since
they do not see any significant immediate benefit.
(Very conservative customers, no C++-needs -- think of it).
 He claimed that due to peculiarities with their port -- he
actually mentioned the 16-bit specifics :-( they had to do
"several front end changes", making a merge with egcs or gcc2
problematic.

(Of course this may or may be outdated information for egcs; my
(under?)educated guess is that some or all of the problems are
"Pmode/SImode"-related problems that some 64-bit targets ran
into long-but-not-too-long ago and that are already solved).

brgds, H-P

Re: NEC 78400 (78K.IV)

[Jeffrey A Law]

  In message < 199810261532.QAA00474@appel.flower >you write:
  > The approach in the i386 backend seems to be to 'define' the register
  > pairs as the true registers (ax,dx,cx), and have aliases for the higher
  > and lower words, ({"ah", 0}, {"al", 0} or something similar).  Something
  > like this doesn't seem fit for the K4, because the 24bit register groups
  > do not cover all registers; and in fact, most operations will be 16 bit
  > anyway.  Therefore, it seems logical to define the K4 as having 8 16bit
  > registers; but how to define the 24bit register groups?
  > 
  > Where can i find more to read on the subject; the md.tex doesn't 
  > seem to address this problem?
I believe you're best off describing the 16bit pairings.  Avoid any 24bit
operations unless absolutely necessary (gcc does not handle ops with a size
that is not 2**n well).

You'll have to experiment some since this target does not match any other
supported targets.

jeff

Re: NEC 78400 (78K.IV)

[Jan Nieuwenhuizen]

On Monday, 12 October 1998, Jeffrey A Law writes:

> Pre-history.  GCC has been dealling with 16bit machines for a while
> now.  The h8 and mn102 are still active (unlike the pdp11, 1750a and dsp16xx)
    + .
> 
> Usually the biggest problem with supporting 16bit ports is a lack of register
    + s,
> segmented addresses, and 16bit targets with 24bit addresses.
> 
>   > Eh, how much work?  Let's say a couple of months for starters;
>   > it "depends".
> It "depends" is about as precise as anyone can get :-)  The closer any new
> chip resembles an existing port the faster one can get a port going.

Thanks for all your comments.  I was getting curious and would like 
to find out for myself what a 78400 port would be like.  What's more,
there's a fair chance my employer is going to donate a slice of my time 
to investigate further and start this port.  Although it won't be much,
i'll be able to put in a bit of time myself.  If more people would want
to do so... who knows.

Anyway, this morning i had a look at the backend config files for the h8 
and mn102 ports.  I don't really know where to start off, but it seemed
logical to start looking at the hardware registers, how they're used,
and what processor would bare the most resemblance.

At that time, i was already getting a bit confused: how many registers
does the K4 have?  It has three ways of register access: it has 16 simple
8bit registers r0..r15.  Then there are eight 16bit register pairs: 
rp0..rp7, and four 24bit register groups, rg4..rg7.  Most operations are 
16bit or 8bit, and some are 24bit.

The approach in the i386 backend seems to be to 'define' the register
pairs as the true registers (ax,dx,cx), and have aliases for the higher
and lower words, ({"ah", 0}, {"al", 0} or something similar).  Something
like this doesn't seem fit for the K4, because the 24bit register groups
do not cover all registers; and in fact, most operations will be 16 bit
anyway.  Therefore, it seems logical to define the K4 as having 8 16bit
registers; but how to define the 24bit register groups?

Where can i find more to read on the subject; the md.tex doesn't 
seem to address this problem?

Greetings,

Jan.

Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.xs4all.nl/~jantien/lilypond