PDP-10 backend for gcc

PDP-10 backend for gcc

[lars brinkhoff]

I may be writing a PDP-10 backend for gcc during the next year.  It's
a word-adressed 36-bit machine with a 30-bit virtual address space.
Is there anything I should know before I start?

Also, the project involves porting gcc to the PDP-10 operating system
TOPS-20.  A GNU build environment is already ported.

Re: PDP-10 backend for gcc

[Michael Meissner]

On Thu, Aug 24, 2000 at 07:50:09AM +0200, lars brinkhoff wrote:
> I may be writing a PDP-10 backend for gcc during the next year.  It's
> a word-adressed 36-bit machine with a 30-bit virtual address space.
> Is there anything I should know before I start?
> 
> Also, the project involves porting gcc to the PDP-10 operating system
> TOPS-20.  A GNU build environment is already ported.

Expect lots of problems.  GCC really, really does not understand pointers that
have different formats, most of which are part of the original design decisions
(ie, very hard to root out after 13+ years).

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482

Re: PDP-10 backend for gcc

[lars brinkhoff]

Michael Meissner <meissner@cygnus.com> writes:
> On Thu, Aug 24, 2000 at 07:50:09AM +0200, lars brinkhoff wrote:
> > I may be writing a PDP-10 backend for gcc during the next year.  It's
> > a word-adressed 36-bit machine with a 30-bit virtual address space.
> > Is there anything I should know before I start?
> Expect lots of problems.  GCC really, really does not understand
> pointers that have different formats, most of which are part of the
> original design decisions (ie, very hard to root out after 13+
> years).

Ouch.  What is the nature of the problems?  When are pointers to
different objects mixed?

Pointers to objects at least one word in size (int, long, long long,
float, double, maybe short) all have the address of the word in the
lower 30 bits.  Pointers to objects less than one word in size (char,
maybe short) uses the 6 upper bits to specify the location of the
object within a word.  The lower 30 bits specify the address of the
word.  Thus, only the 6 upper bits would have to be modified when,
say, casting from one pointer type to another.

Does it seem like it would be possible to write a back end using these
pointer formats?

Re: PDP-10 backend for gcc

[lars brinkhoff]

Alan Lehotsky <lehotsky@tiac.net> writes:
> At 8:05 AM +0200 8/25/00, lars brinkhoff wrote:
> > > On Thu, Aug 24, 2000 at 07:50:09AM +0200, lars brinkhoff wrote:
> > > > I may be writing a PDP-10 backend for gcc during the next year.  It's
> > > > a word-adressed 36-bit machine with a 30-bit virtual address space.
> > Does it seem like it would be possible to write a back end using these
> > pointer formats?
> 
> I've worked on a compiler that supported TWO different sized pointers
> (24 and 32 bits) and there are a lot of problems. [I also worked on
> a compiler for the DEC-10 (Bliss36), so I know a lot about your
> target machine. [If you need someone to bounce ideas off, feel free
> to mail me....]

Thanks!

> The biggest problem you will encounter is the fact that the way that
> RTL is currently generated, you don't really get the opportunity to
> provide any type information about a pointer.  There's basically
> a Pmode that's supposed to be correct for ALL pointers.

So, a hack to make gcc support two pointer formats (global one-word
byte pointers and ordinary global pointers) could be a quick-and-
dirty solution?

> Certainly, if you wanted to sacrifice performance, you could make
> ALL pointers be byte-pointer format (with 36 bit fields) and
> pretty much everything would work.

The problem with this is that one-word global byte pointers can't
point to 36-bit bytes.  (Or so I'm told.)

> Alternatively, you may need to propose an extension to the RTL and 
> the code generator generator so that you can maintain the necessary 
> type information.
> 
> IMHO, such an extension would be a major contribution to the GCC
> community, because these problems keep cropping up in DSP ports
> and the current solutions are less than satisfactory.

I'm quite willing to try this, but I'm not sure that my employer want
to pay for it.

Re: PDP-10 backend for gcc

[Alan Lehotsky]

At 8:04 AM +0200 8/29/00, lars brinkhoff wrote:
>Alan Lehotsky <lehotsky@tiac.net> writes:
>>  At 8:05 AM +0200 8/25/00, lars brinkhoff wrote:
>>  > > On Thu, Aug 24, 2000 at 07:50:09AM +0200, lars brinkhoff wrote:
>>  > > > I may be writing a PDP-10 backend for gcc during the next year.  It's
>>  > > > a word-adressed 36-bit machine with a 30-bit virtual address space.
>>  > Does it seem like it would be possible to write a back end using these
>>  > pointer formats?
>>
>>  I've worked on a compiler that supported TWO different sized pointers
>>  (24 and 32 bits) and there are a lot of problems. [I also worked on
>>  a compiler for the DEC-10 (Bliss36), so I know a lot about your
>>  target machine. [If you need someone to bounce ideas off, feel free
>>  to mail me....]
>
>Thanks!
>
>>  The biggest problem you will encounter is the fact that the way that
>>  RTL is currently generated, you don't really get the opportunity to
>>  provide any type information about a pointer.  There's basically
>>  a Pmode that's supposed to be correct for ALL pointers.
>
>So, a hack to make gcc support two pointer formats (global one-word
>byte pointers and ordinary global pointers) could be a quick-and-
>dirty solution?


	Well, it wouldn't be THAT dirty, other than requiring you to
	be careful about using PSI mode for all pointers and making
	sure that all pointer arithmetic used IBP instructions not
	regular ADDs/SUBs.

	It just would run somewhat slower and prevent you from using
	the full glory of the PDP-10 addressing modes. :-)


>  > Certainly, if you wanted to sacrifice performance, you could make
>>  ALL pointers be byte-pointer format (with 36 bit fields) and
>>  pretty much everything would work.
>
>The problem with this is that one-word global byte pointers can't
>point to 36-bit bytes.  (Or so I'm told.)


	It's been a long time since I've looked at the telephone
	book for the KL-10 :-).  But, as I recall the 30 bits weren't
	normally directly addressable.  The 36 bit word of a byte pointer
	had something like

		- an indirect bit
		- a 6 bit bit position
		- a 6 bit field size
		- 4 or 5 bits for index register?
		  (gee, I wrote code for this machine for 5
		   years and I can't remember now....)
		- 18 bits of offset.

>  > Alternatively, you may need to propose an extension to the RTL and
>>  the code generator generator so that you can maintain the necessary
>>  type information.
>>
>>  IMHO, such an extension would be a major contribution to the GCC
>>  community, because these problems keep cropping up in DSP ports
>>  and the current solutions are less than satisfactory.
>
>I'm quite willing to try this, but I'm not sure that my employer want
>to pay for it.

	It would be a lot of work, but depending on how good a
	compiler you need, it might be worth it.

	-- Al Lehotsky
-- 
------------------------------------------------------------------------

		    Quality Software Management
		http://www.tiac.net/users/qsmgmt
			apl@alum.mit.edu
			(978)287-0435 Voice
			(978)808-6836 Cell
			(978)287-0436 Fax

	Software Process Improvement and Management Consulting
	     Language Design and Compiler Implementation

Re: PDP-10 backend for gcc

[lars brinkhoff]

[gcc mailing list brought back in the discussion, because it's (hopefully)
 of general interest]

Alan Lehotsky <lehotsky@tiac.net> writes:
> >Ok.  How about this idea: Pointers are represented internally as
> >normal integers, using integer arithmetic etc, and only converted
> >to PDP-10 pointer format just before emitting assembly output?
> 
> 	Won't work - you can't tag integers and the back-end won't
> 	be able to figure out when an integer is part of a pointer
> 	and when it's just adding 1 to a variable.
> 
> 	The RTL phase discards almost ALL language type information and
> 	only operates on things in 'enum machine_mode', which is
> 	basically just an enumeration of basic data types of fundemental
> 	sizes (viz.  QImode, HImode, SImode...)

Oh.  But the back end MUST know whether it's operating on pointers or
integers.  Byte pointer subtraction on a PDP-10 is much different from
integer subtraction.  Basically, PDP-10 byte pointers are not are not
integers, at least not with respect to how arithmetic are performed on
them.

So, does adding some kind of proper Pmode (not just a #define as it is
now, according to gcc documentation) for byte pointers sound appropriate?

Word pointers are like integers, so PSImode could be used for them.

> >In the PDP-10 case, the 30-bit word address space would be represented
> >as a 32-bit char address space, because there are four 9-bit chars in
> >a word.  Pointers could be converted by something like
> 
> 	I guess I don't understand quite what you're proposing.

I was proposing that all pointer values are represented internally as
32-bit linear byte addresses, just as they are now.  Only when a
pointer is written to output is it converted to a PDP-10 byte pointer
or word address.

E.i.

internal gcc pointer    PDP-10 pointer
type      value         (octal representation, ",," separates half-words)

(char *)  0             700000,,000000
(char *)  1             710000,,000000
(char *)  2             720000,,000000
(char *)  3             730000,,000000          these are all global
(char *)  4             700000,,000001          byte pointers for 9-bit
(char *)  5             710000,,000001          bytes, i.e. chars
(char *)  6             720000,,000001
(char *)  7             730000,,000001
(char *)  8             700000,,000002

(short *) 0             750000,,000000
(short *) 2             760000,,000000          these are all global
(short *) 4             750000,,000001          byte pointers for 18-bit
(short *) 6             760000,,000001          bytes, i.e. shorts
(short *) 8             750000,,000002

(int *)   0             000000,,000000
(int *)   4             000000,,000001
(int *)   8             000000,,000002

(long long *)0          000000,,000000
(long long *)8          000000,,000002

(Modulo any compilcations for the NULL pointer.)

Re: PDP-10 backend for gcc

[lars brinkhoff]

Alan Lehotsky <lehotsky@tiac.net> writes:
> 	It also occurs to me that you are going to have OTHER troubles
> 	unless you host on either the PDP-10 - (is there an existing C
> 	compiler) or run on an Alpha in 64 bit mode.

Yes, the plan is to host on a PDP-10, and yes, there is an existing C
compiler (called KCC), though I don't know of how much use it will be.

I guess the problem with hosting on 32-bit machies is that
calculations are done using int in gcc?  How about HOST_WIDE_INT?

Re: PDP-10 backend for gcc

[Jeffrey A Law]

  In message < 857l8ylv6b.fsf@junk.nocrew.org >you write:
  > Alan Lehotsky <lehotsky@tiac.net> writes:
  > > 	Won't work - you can't tag integers and the back-end won't
  > > 	be able to figure out when an integer is part of a pointer
  > > 	and when it's just adding 1 to a variable.
  > > 
  > > 	The RTL phase discards almost ALL language type information and
  > > 	only operates on things in 'enum machine_mode', which is
  > > 	basically just an enumeration of basic data types of fundemental
  > > 	sizes (viz.  QImode, HImode, SImode...)
  > 
  > Oh.  But the back end MUST know whether it's operating on pointers or
  > integers.  Byte pointer subtraction on a PDP-10 is much different from
  > integer subtraction.  Basically, PDP-10 byte pointers are not are not
  > integers, at least not with respect to how arithmetic are performed on
  > them.
You've got a significant problem then.  You're most likely going to have
to use something like PSImode or PDImode or something new to represent
your pointers.

Fundamentally GCC assumes that arithmetic on pointer types works just
like arithmetic on integer types.

jeff

Re: PDP-10 backend for gcc

[lars brinkhoff]

Jeffrey A Law <law@cygnus.com> writes:
> > Oh.  But the back end MUST know whether it's operating on pointers or
> > integers.  Byte pointer subtraction on a PDP-10 is much different from
> > integer subtraction.  Basically, PDP-10 byte pointers are not are not
> > integers, at least not with respect to how arithmetic are performed on
> > them.
> You've got a significant problem then.  You're most likely going to have
> to use something like PSImode or PDImode or something new to represent
> your pointers.
> 
> Fundamentally GCC assumes that arithmetic on pointer types works just
> like arithmetic on integer types.

There are two kinds of pointers:

  Word pointers.  These are 30-bit values in 36-bit words, and are
  used to point to anything at least one word in size.  Integer
  arithmetic works.  I think PSImode will work here.

  Byte[*] pointers.  These are 36-bit values in 36-bit words.  The
  lower 30 bits is a word pointer, and the upper 6 bits is a code
  to locate the byte (i.e. char or short) within the word pointed
  to.  Since normal ints are 36-bits, SImode can't be used for byte
  pointers.  Maybe a new mode will have to be invented?

[*] On a PDP-10 a "byte" is defined as any contigous bit field in a
36-bit word.

Re: PDP-10 backend for gcc

[Torbjorn Granlund]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 510 bytes --]

I made a quick GCC port to the pdp10 back in 1996.  I ignored the
problems of pointers, and had char, short, and int to all be 36-bit
opjects.  It uses QImode for 36-bit types, which I think is the
correct approach.

I think my port could be a starting point for a port with proper byte
handling, since it actually generates reasonable code for plain
arithmetic.  It shouldn't be take too much trouble to make it work in
current GCC.

I'll make my port available for ftp if there is interest.

-- 
Torbjörn

Re: PDP-10 backend for gcc

[Michael Meissner]

On Fri, Sep 01, 2000 at 11:16:06AM +0200, lars brinkhoff wrote:
> Jeffrey A Law <law@cygnus.com> writes:
> > > Oh.  But the back end MUST know whether it's operating on pointers or
> > > integers.  Byte pointer subtraction on a PDP-10 is much different from
> > > integer subtraction.  Basically, PDP-10 byte pointers are not are not
> > > integers, at least not with respect to how arithmetic are performed on
> > > them.
> > You've got a significant problem then.  You're most likely going to have
> > to use something like PSImode or PDImode or something new to represent
> > your pointers.
> > 
> > Fundamentally GCC assumes that arithmetic on pointer types works just
> > like arithmetic on integer types.
> 
> There are two kinds of pointers:
> 
>   Word pointers.  These are 30-bit values in 36-bit words, and are
>   used to point to anything at least one word in size.  Integer
>   arithmetic works.  I think PSImode will work here.
> 
>   Byte[*] pointers.  These are 36-bit values in 36-bit words.  The
>   lower 30 bits is a word pointer, and the upper 6 bits is a code
>   to locate the byte (i.e. char or short) within the word pointed
>   to.  Since normal ints are 36-bits, SImode can't be used for byte
>   pointers.  Maybe a new mode will have to be invented?
> 
> [*] On a PDP-10 a "byte" is defined as any contigous bit field in a
> 36-bit word.

Sorry, I was not replying to external mail for a few days.  As the others have
said, GCC internally believes that all pointers are byte pointers, and it can
just add 1 to a pointer to increment to the next byte.  That means without
reworking the code, you would not be able to use any other format, such as
using the upper bits for the byte offset, etc.

If I remember my computer architecture classes, the classical way to represent
characters on a -10 was to have 5 7-bit fields with a bit left over.  This
violates ISO C, which mandates that all types be a whole number of bytes (so
that memcpy works), and that a byte be at least 8 bits.  This would mean you
would have to use either 36-bit bytes, or 9-bit bytes.  The path of least
reistance is to have 36-bit 'bytes'.  This is the path chosen by other word
oriented machines, such as the C4x.

It would be useful to have GCC be able to deal with different sized pointers
and/or different encodings for the pointers.  I have run into this on some
machines, such as the Mitsubshi D10V (function pointers are 16-bit word
pointers, while data pointers are 16-bit byte pointers), but I suspect you will
have to get buy-in from the people that work on the front ends (ie, the TREE
interface), since that is where a lot of the work will need to be done.  Given
this byte pointer-ness has been in the compiler since its inception, I suspect
you will find undocumented assumptions rife throughout the compiler.

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482

Re: PDP-10 backend for gcc

[Andrew Morton]

Michael Meissner wrote:
> 
> Given this byte pointer-ness has been in the compiler
> since its inception, I suspect you will find
> undocumented assumptions rife throughout the compiler.

You suspect correctly.  I once ported gcc/g++ 2.5.8 to a
bit-addressable machine.  A machine where you have to add
8 to an address register to advance it by a byte.

I found thirty or forty instances of this byte == 1
assumption, and basically the only way of tracking
them down was working backwards from incorrect
code generation.

Even though 2.5.8 is not entirely state-of-the-art,
if someone actually intends to go through this exercise,
the stuff at http://www.uow.edu.au/~andrewm/gsptools.html
will save them a couple of weeks work.

Re: PDP-10 backend for gcc

[lars brinkhoff]

Michael Meissner <meissner@cygnus.com> writes:
> > There are two kinds of pointers:
> > 
> >   Word pointers.  These are 30-bit values in 36-bit words, and are
> >   used to point to anything at least one word in size.  Integer
> >   arithmetic works.  I think PSImode will work here.
> > 
> >   Byte pointers.  These are 36-bit values in 36-bit words.  The
> >   lower 30 bits is a word pointer, and the upper 6 bits is a code
> >   to locate the byte (i.e. char or short) within the word pointed
> >   to.  Since normal ints are 36-bits, SImode can't be used for byte
> >   pointers.  Maybe a new mode will have to be invented?
> 
> As the others have said, GCC internally believes that all pointers
> are byte pointers, and it can just add 1 to a pointer to increment
> to the next byte.  That means without reworking the code, you would
> not be able to use any other format, such as using the upper bits
> for the byte offset, etc.

I even found a reference to this in Using and Porting GCC, section
RTL Template.

`(address (match_operand:M N "address_operand" ""))'
     This complex of expressions is a placeholder for an operand number
     N in a "load address" instruction: an operand which specifies a
     memory location in the usual way, but for which the actual operand
     value used is the address of the location, not the contents of the
     location.

     `address' expressions never appear in RTL code, only in machine
     descriptions.  And they are used only in machine descriptions that
     do not use the operand constraint feature.  When operand
     constraints are in use, the letter `p' in the constraint serves
     this purpose.

     M is the machine mode of the *memory location being addressed*,
     not the machine mode of the address itself.  That mode is always
     the same on a given target machine (it is `Pmode', which normally
     is `SImode'), so there is no point in mentioning it; thus, no
     machine mode is written in the `address' expression.  If some day
     support is added for machines in which addresses of different
     kinds of objects appear differently or are used differently (such
     as the PDP-10), different formats would perhaps need different
     machine modes and these modes might be written in the `address'
     expression.

The PDP-10 may need three pointer machine modes, perhaps named like this:
        QIPmode         pointer to char
        HIPmode         pointer to short
        SIPmode         pointer to objects at least an int in size

> If I remember my computer architecture classes, the classical way to
> represent characters on a -10 was to have 5 7-bit fields with a bit
> left over.  This violates ISO C, which mandates that all types be a
> whole number of bytes (so that memcpy works), and that a byte be at
> least 8 bits.  This would mean you would have to use either 36-bit
> bytes, or 9-bit bytes.  The path of least reistance is to have
> 36-bit 'bytes'.  This is the path chosen by other word oriented
> machines, such as the C4x.

9-bit chars will probably be used.  I don't think that 36-bit chars
would be acceptable.  When doing text I/O, the 7-bit characters will
be zero-extended to 9 bits.

> It would be useful to have GCC be able to deal with different sized
> pointers and/or different encodings for the pointers.  I have run
> into this on some machines, such as the Mitsubshi D10V (function
> pointers are 16-bit word pointers, while data pointers are 16-bit
> byte pointers), but I suspect you will have to get buy-in from the
> people that work on the front ends (ie, the TREE interface), since
> that is where a lot of the work will need to be done.  Given this
> byte pointer-ness has been in the compiler since its inception, I
> suspect you will find undocumented assumptions rife throughout the
> compiler.

I was hoping that the front ends would not be affected much at all.
Say, if the back end is presented with a constant char *, it could
do the necessary translation into a PDP-10 byte pointer.  Similarly,
there could be machine description patterns for pointer arithmetic.

Re: PDP-10 backend for gcc

[lars brinkhoff]

Andrew Morton <andrewm@uow.edu.au> writes:
> Michael Meissner wrote:
> > Given this byte pointer-ness has been in the compiler
> > since its inception, I suspect you will find
> > undocumented assumptions rife throughout the compiler.
> 
> You suspect correctly.  I once ported gcc/g++ 2.5.8 to a
> bit-addressable machine.  A machine where you have to add
> 8 to an address register to advance it by a byte.
> 
> I found thirty or forty instances of this byte == 1
> assumption, and basically the only way of tracking
> them down was working backwards from incorrect
> code generation.

Isn't it about time gcc was enhanced to support "weird" pointers?

Re: PDP-10 backend for gcc

[Michael Meissner]

On Wed, Sep 06, 2000 at 11:18:00AM +0200, lars brinkhoff wrote:
> Andrew Morton <andrewm@uow.edu.au> writes:
> > Michael Meissner wrote:
> > > Given this byte pointer-ness has been in the compiler
> > > since its inception, I suspect you will find
> > > undocumented assumptions rife throughout the compiler.
> > 
> > You suspect correctly.  I once ported gcc/g++ 2.5.8 to a
> > bit-addressable machine.  A machine where you have to add
> > 8 to an address register to advance it by a byte.
> > 
> > I found thirty or forty instances of this byte == 1
> > assumption, and basically the only way of tracking
> > them down was working backwards from incorrect
> > code generation.
> 
> Isn't it about time gcc was enhanced to support "weird" pointers?

Sure I do.  FYI, since I wrote a (non GCC) C compiler front end for a machine
with weird pointers (Data General MV/Eclipse, RIP) and supported it for 5
years, I can certainly agree that it is needed.  However, I tend to have much
more on my plate than I can code....

I'm just warning you that it is a big job.  Even after you are done, be
prepapred to find that a lot of net code will fail due to many C programmers
being unable to figure out that logically each different type of pointer can
potentially have a different size or layout, other than the char * == void *,
and all struct/union pointers must have the same size and layout requirements
that are in the C standards.

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482

Re: PDP-10 backend for gcc

[lars brinkhoff]

Michael Meissner <meissner@cygnus.com> writes:
> On Wed, Sep 06, 2000 at 11:18:00AM +0200, lars brinkhoff wrote:
> > Isn't it about time gcc was enhanced to support "weird" pointers?
>
> [...] I can certainly agree that it is needed.  However, I tend to
> have much more on my plate than I can code....
> 
> I'm just warning you that it is a big job.

That is understood.  But I'm interested in working on it if the GCC
maintainers think it's a good idea.

Re: PDP-10 backend for gcc

[Nick Ing-Simmons]

Michael Meissner <meissner@cygnus.com> writes:
>
>It would be useful to have GCC be able to deal with different sized pointers
>and/or different encodings for the pointers.  I have run into this on some
>machines, such as the Mitsubshi D10V (function pointers are 16-bit word
>pointers, while data pointers are 16-bit byte pointers), but I suspect you will
>have to get buy-in from the people that work on the front ends (ie, the TREE
>interface), since that is where a lot of the work will need to be done.  Given
>this byte pointer-ness has been in the compiler since its inception, I suspect
>you will find undocumented assumptions rife throughout the compiler.

Way back at gcc-1.* I tried to do a port to TI's TMS340XX processors
which were(are?) bit addressed. The machine description macros in GCC
allowed this to be described just fine - but the code turned out to be 
littered with assumptions and non-use of the macros which made the 
whole process really hard.


-- 
Nick Ing-Simmons <nik@tiuk.ti.com>
Via, but not speaking for: Texas Instruments Ltd.

Re: PDP-10 backend for gcc

[Michael Meissner]

On Sat, Sep 12, 1970 at 07:22:42AM -0400, Richard Kenner wrote:
>     That is understood.  But I'm interested in working on it if the GCC
>     maintainers think it's a good idea.
> 
> Am I misremembering or is the PDP-10 one's complement?  If so, that's another
> issue, though a somewhat more minor one.

I suspect you are mixing it up with the Univac 110x series, which was 36 bit,
1's complement (then there was CDC with 60 bit 1's complement, and Burroughs n
bit, signed magnitude -- at the ANSI meetings, we had several vendors
representing now unusual designs).

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482

Re: PDP-10 backend for gcc

[lars brinkhoff]

kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:
>     That is understood.  But I'm interested in working on it if the GCC
>     maintainers think it's a good idea.
> Am I misremembering or is the PDP-10 one's complement?  If so,
> that's another issue, though a somewhat more minor one.

No, it's two's complement.

Re: PDP-10 backend for gcc

[Richard Kenner]

    That is understood.  But I'm interested in working on it if the GCC
    maintainers think it's a good idea.

Am I misremembering or is the PDP-10 one's complement?  If so, that's another
issue, though a somewhat more minor one.