* PDP-10 backend for gcc @ 2000-08-23 22:50 lars brinkhoff 2000-08-24 8:36 ` Michael Meissner 0 siblings, 1 reply; 20+ messages in thread From: lars brinkhoff @ 2000-08-23 22:50 UTC (permalink / raw) To: gcc 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: PDP-10 backend for gcc 2000-08-23 22:50 PDP-10 backend for gcc lars brinkhoff @ 2000-08-24 8:36 ` Michael Meissner 2000-08-24 23:43 ` lars brinkhoff 0 siblings, 1 reply; 20+ messages in thread From: Michael Meissner @ 2000-08-24 8:36 UTC (permalink / raw) To: lars brinkhoff; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: PDP-10 backend for gcc 2000-08-24 8:36 ` Michael Meissner @ 2000-08-24 23:43 ` lars brinkhoff [not found] ` <p04320400b5cc15b2e9eb@[192.168.1.254]> 0 siblings, 1 reply; 20+ messages in thread From: lars brinkhoff @ 2000-08-24 23:43 UTC (permalink / raw) To: Michael Meissner; +Cc: gcc 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? ^ permalink raw reply [flat|nested] 20+ messages in thread
[parent not found: <p04320400b5cc15b2e9eb@[192.168.1.254]>]
* Re: PDP-10 backend for gcc [not found] ` <p04320400b5cc15b2e9eb@[192.168.1.254]> @ 2000-08-28 23:05 ` lars brinkhoff 2000-08-29 6:57 ` Alan Lehotsky 0 siblings, 1 reply; 20+ messages in thread From: lars brinkhoff @ 2000-08-28 23:05 UTC (permalink / raw) To: Alan Lehotsky; +Cc: gcc 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: PDP-10 backend for gcc 2000-08-28 23:05 ` lars brinkhoff @ 2000-08-29 6:57 ` Alan Lehotsky [not found] ` <85vgwkcf28.fsf@junk.nocrew.org> 0 siblings, 1 reply; 20+ messages in thread From: Alan Lehotsky @ 2000-08-29 6:57 UTC (permalink / raw) To: lars brinkhoff; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
[parent not found: <85vgwkcf28.fsf@junk.nocrew.org>]
[parent not found: <p04330106b5d17d9f5e1c@[192.168.1.254]>]
[parent not found: <8566ojn920.fsf@junk.nocrew.org>]
[parent not found: <p0433010fb5d1d473ca3a@[192.168.1.254]>]
[parent not found: <85itsjkum2.fsf@junk.nocrew.org>]
[parent not found: <p04330103b5d2adea14ec@[192.168.1.254]>]
* Re: PDP-10 backend for gcc [not found] ` <p04330103b5d2adea14ec@[192.168.1.254]> @ 2000-08-30 6:45 ` lars brinkhoff [not found] ` <p04330104b5d2c3902b09@[192.168.1.254]> 2000-08-31 23:09 ` Jeffrey A Law 0 siblings, 2 replies; 20+ messages in thread From: lars brinkhoff @ 2000-08-30 6:45 UTC (permalink / raw) To: Alan Lehotsky; +Cc: gcc [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.) ^ permalink raw reply [flat|nested] 20+ messages in thread
[parent not found: <p04330104b5d2c3902b09@[192.168.1.254]>]
* Re: PDP-10 backend for gcc [not found] ` <p04330104b5d2c3902b09@[192.168.1.254]> @ 2000-08-30 23:24 ` lars brinkhoff 0 siblings, 0 replies; 20+ messages in thread From: lars brinkhoff @ 2000-08-30 23:24 UTC (permalink / raw) To: Alan Lehotsky; +Cc: gcc 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? ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: PDP-10 backend for gcc 2000-08-30 6:45 ` lars brinkhoff [not found] ` <p04330104b5d2c3902b09@[192.168.1.254]> @ 2000-08-31 23:09 ` Jeffrey A Law 2000-09-01 2:16 ` lars brinkhoff 1 sibling, 1 reply; 20+ messages in thread From: Jeffrey A Law @ 2000-08-31 23:09 UTC (permalink / raw) To: lars brinkhoff; +Cc: Alan Lehotsky, gcc 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: PDP-10 backend for gcc 2000-08-31 23:09 ` Jeffrey A Law @ 2000-09-01 2:16 ` lars brinkhoff 2000-09-01 2:40 ` Torbjorn Granlund 2000-09-05 16:05 ` Michael Meissner 0 siblings, 2 replies; 20+ messages in thread From: lars brinkhoff @ 2000-09-01 2:16 UTC (permalink / raw) To: law; +Cc: Alan Lehotsky, gcc 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: PDP-10 backend for gcc 2000-09-01 2:16 ` lars brinkhoff @ 2000-09-01 2:40 ` Torbjorn Granlund 2000-09-05 16:05 ` Michael Meissner 1 sibling, 0 replies; 20+ messages in thread From: Torbjorn Granlund @ 2000-09-01 2:40 UTC (permalink / raw) To: lars brinkhoff; +Cc: law, Alan Lehotsky, gcc [-- 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: PDP-10 backend for gcc 2000-09-01 2:16 ` lars brinkhoff 2000-09-01 2:40 ` Torbjorn Granlund @ 2000-09-05 16:05 ` Michael Meissner 2000-09-05 16:54 ` Andrew Morton ` (2 more replies) 1 sibling, 3 replies; 20+ messages in thread From: Michael Meissner @ 2000-09-05 16:05 UTC (permalink / raw) To: lars brinkhoff; +Cc: law, Alan Lehotsky, gcc 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: PDP-10 backend for gcc 2000-09-05 16:05 ` Michael Meissner @ 2000-09-05 16:54 ` Andrew Morton 2000-09-06 2:18 ` lars brinkhoff 2000-09-06 2:15 ` lars brinkhoff 2000-09-13 5:17 ` Nick Ing-Simmons 2 siblings, 1 reply; 20+ messages in thread From: Andrew Morton @ 2000-09-05 16:54 UTC (permalink / raw) To: Michael Meissner; +Cc: lars brinkhoff, law, Alan Lehotsky, gcc 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: PDP-10 backend for gcc 2000-09-05 16:54 ` Andrew Morton @ 2000-09-06 2:18 ` lars brinkhoff 2000-09-06 15:56 ` Michael Meissner 0 siblings, 1 reply; 20+ messages in thread From: lars brinkhoff @ 2000-09-06 2:18 UTC (permalink / raw) To: Andrew Morton; +Cc: Michael Meissner, law, Alan Lehotsky, gcc 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? ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: PDP-10 backend for gcc 2000-09-06 2:18 ` lars brinkhoff @ 2000-09-06 15:56 ` Michael Meissner 2000-09-06 23:19 ` lars brinkhoff 0 siblings, 1 reply; 20+ messages in thread From: Michael Meissner @ 2000-09-06 15:56 UTC (permalink / raw) To: lars brinkhoff; +Cc: Andrew Morton, Michael Meissner, law, Alan Lehotsky, gcc 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: PDP-10 backend for gcc 2000-09-06 15:56 ` Michael Meissner @ 2000-09-06 23:19 ` lars brinkhoff 0 siblings, 0 replies; 20+ messages in thread From: lars brinkhoff @ 2000-09-06 23:19 UTC (permalink / raw) To: Michael Meissner; +Cc: Andrew Morton, law, Alan Lehotsky, gcc 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: PDP-10 backend for gcc 2000-09-05 16:05 ` Michael Meissner 2000-09-05 16:54 ` Andrew Morton @ 2000-09-06 2:15 ` lars brinkhoff 2000-09-13 5:17 ` Nick Ing-Simmons 2 siblings, 0 replies; 20+ messages in thread From: lars brinkhoff @ 2000-09-06 2:15 UTC (permalink / raw) To: Michael Meissner; +Cc: law, Alan Lehotsky, gcc 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: PDP-10 backend for gcc 2000-09-05 16:05 ` Michael Meissner 2000-09-05 16:54 ` Andrew Morton 2000-09-06 2:15 ` lars brinkhoff @ 2000-09-13 5:17 ` Nick Ing-Simmons 2 siblings, 0 replies; 20+ messages in thread From: Nick Ing-Simmons @ 2000-09-13 5:17 UTC (permalink / raw) To: meissner; +Cc: gcc, Alan Lehotsky, law, lars brinkhoff 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: PDP-10 backend for gcc @ 2000-09-12 4:09 Richard Kenner 2000-09-12 4:10 ` lars brinkhoff 2000-09-12 8:43 ` Michael Meissner 0 siblings, 2 replies; 20+ messages in thread From: Richard Kenner @ 2000-09-12 4:09 UTC (permalink / raw) To: lars; +Cc: gcc 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: PDP-10 backend for gcc 2000-09-12 4:09 Richard Kenner @ 2000-09-12 4:10 ` lars brinkhoff 2000-09-12 8:43 ` Michael Meissner 1 sibling, 0 replies; 20+ messages in thread From: lars brinkhoff @ 2000-09-12 4:10 UTC (permalink / raw) To: Richard Kenner; +Cc: gcc 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: PDP-10 backend for gcc 2000-09-12 4:09 Richard Kenner 2000-09-12 4:10 ` lars brinkhoff @ 2000-09-12 8:43 ` Michael Meissner 1 sibling, 0 replies; 20+ messages in thread From: Michael Meissner @ 2000-09-12 8:43 UTC (permalink / raw) To: Richard Kenner; +Cc: lars, gcc 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2000-09-13 5:17 UTC | newest] Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-08-23 22:50 PDP-10 backend for gcc lars brinkhoff 2000-08-24 8:36 ` Michael Meissner 2000-08-24 23:43 ` lars brinkhoff [not found] ` <p04320400b5cc15b2e9eb@[192.168.1.254]> 2000-08-28 23:05 ` lars brinkhoff 2000-08-29 6:57 ` Alan Lehotsky [not found] ` <85vgwkcf28.fsf@junk.nocrew.org> [not found] ` <p04330106b5d17d9f5e1c@[192.168.1.254]> [not found] ` <8566ojn920.fsf@junk.nocrew.org> [not found] ` <p0433010fb5d1d473ca3a@[192.168.1.254]> [not found] ` <85itsjkum2.fsf@junk.nocrew.org> [not found] ` <p04330103b5d2adea14ec@[192.168.1.254]> 2000-08-30 6:45 ` lars brinkhoff [not found] ` <p04330104b5d2c3902b09@[192.168.1.254]> 2000-08-30 23:24 ` lars brinkhoff 2000-08-31 23:09 ` Jeffrey A Law 2000-09-01 2:16 ` lars brinkhoff 2000-09-01 2:40 ` Torbjorn Granlund 2000-09-05 16:05 ` Michael Meissner 2000-09-05 16:54 ` Andrew Morton 2000-09-06 2:18 ` lars brinkhoff 2000-09-06 15:56 ` Michael Meissner 2000-09-06 23:19 ` lars brinkhoff 2000-09-06 2:15 ` lars brinkhoff 2000-09-13 5:17 ` Nick Ing-Simmons 2000-09-12 4:09 Richard Kenner 2000-09-12 4:10 ` lars brinkhoff 2000-09-12 8:43 ` Michael Meissner
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).