Re: RFC: named address space support
Hi Joseph .. the embedded C proposal as of 2008-01-18 is at stage 90.92. This suggests that it's very close to being incorporated into the standard. Have I understood that correctly? No. All it means is that TR 18037 is being revised, not anything to do with the standard. This is a TR Type 2, not an IS, and remains a TR Type 2, not an IS. [snip] Thanks for the run-down on the standards process; very helpful! A TR Type 2 may be considered as indicating if you want a feature to do this, it may be a good idea to do it this way and so gain implementation experience for future standardization. As such, I think it is reasonable to continue to add features from such TRs to GCC, provided we understand that they are experimental and may be changed incompatibly in future to accord with future TR versions or changes in the course of inclusion in the IS; that unlike actual language standards, we will not try to provide options to support different versions of a TR in the same compiler version. (The same applies to informative annexes in an IS, which may have the same sort of content as a Type 2 TR, such as Annex G in C99.) This (in addition to Mark's comments) sounds perfectly acceptable to me. We want the implementation to be standards compliant; if the standard one day changes the details, we will have to change to be compliant. Until then, the support should have a big neon sign over it that says experimental. Cheers, Ben
Re: RFC: named address space support
On Tue, 15 Apr 2008, Ben Elliston wrote: Hi Mark I'm not terribly familiar with this proposal. Ben, to answer your original question, I don't think that lack of nested address spaces is a fatal flaw, as long as the implementation otherwise meets the spec, and as long as the implementation doesn't somehow make it harder to add that. However, I'd like to know how final this proposal is, and how likely it is to make the WG14 WP. According to: http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=30822 .. the embedded C proposal as of 2008-01-18 is at stage 90.92. This suggests that it's very close to being incorporated into the standard. Have I understood that correctly? No. All it means is that TR 18037 is being revised, not anything to do with the standard. This is a TR Type 2, not an IS, and remains a TR Type 2, not an IS. As I recall, for a long time WG14 had a revised version fixing problems in the original TR, but trouble getting ISO to accept it; all the status means is that ISO is now accepting the revised version for publication. (This revised version is N1275, I think; that should be used in place of N1169.) ISO has nothing to do with whether TRs may be incorporated in the standard in subsequent revisions. It may be involved if a standalone TR changes into a standalone IS, as was proposed for the draft TR 24747 (special mathematical functions), but I think that's the only TR related to ISO C with such a proposal. There is no C1x draft as yet (N1256, C99+TC1+TC2+TC3, is the base document for the revision). I don't think it's been decided which TRs might end up in the base C1x standard, though there's an Austin Group paper arguing that TR 19769 (u and U strings) should remain a TR and not be included in the standard. I don't know what might be being decided at the Delft meeting right now. The agenda has Status of TR 18037 as an unnumbered item. A TR Type 2 may be considered as indicating if you want a feature to do this, it may be a good idea to do it this way and so gain implementation experience for future standardization. As such, I think it is reasonable to continue to add features from such TRs to GCC, provided we understand that they are experimental and may be changed incompatibly in future to accord with future TR versions or changes in the course of inclusion in the IS; that unlike actual language standards, we will not try to provide options to support different versions of a TR in the same compiler version. (The same applies to informative annexes in an IS, which may have the same sort of content as a Type 2 TR, such as Annex G in C99.) -- Joseph S. Myers [EMAIL PROTECTED]
Re: RFC: named address space support
Hi Mark I'm not terribly familiar with this proposal. Ben, to answer your original question, I don't think that lack of nested address spaces is a fatal flaw, as long as the implementation otherwise meets the spec, and as long as the implementation doesn't somehow make it harder to add that. However, I'd like to know how final this proposal is, and how likely it is to make the WG14 WP. According to: http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=30822 .. the embedded C proposal as of 2008-01-18 is at stage 90.92. This suggests that it's very close to being incorporated into the standard. Have I understood that correctly? As always, I'm concerned about putting things into GCC and then finding out that we have to change them in ways that are not backwards compatible. And, I'd like to know what our C maintainers make of the proposal overall; if they see language issues, then we might want to resolve those with WG14. Sure. Any comments from Joseph or Richard? Cheers, Ben
Re: RFC: named address space support
Hi Mark I agree. Much to my dismay, the C and C++ committees don't seem to be willing to work together to make sure that C remains a subset of C++. I'm afraid my patch doesn't address that. :-) Ben, to answer your original question, I don't think that lack of nested address spaces is a fatal flaw, as long as the implementation otherwise meets the spec, and as long as the implementation doesn't somehow make it harder to add that. Good, I was hoping that would be the general opinion. However, I'd like to know how final this proposal is, and how likely it is to make the WG14 WP. I don't really know the answer to that. I will try and find out. Perhaps Chao-ying Fu (cc'ed) who implemented the fixed point arithmetic portion of the proposal knows more? As always, I'm concerned about putting things into GCC and then finding out that we have to change them in ways that are not backwards compatible. Absolutely understood! Cheers, Ben
RFC: named address space support
The Embedded-C spec introduces a number of C language features useful for embedded development. GCC already implements fixed point arithmetic (Chapter 4) from this proposal. http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf Chapter 5 is divided into two sections: named address space support and named-register storage classes. IBM has an implementation of named address space support on the named-addr-spaces-branch that we would like to merge into mainline. Before proceeding, I would like to discuss what would be acceptable to the GCC community. Our implementation only covers section 5.1 of the proposal (named address space support). Section 5.2 has not been implemented. I am conscious that the named address space implementation we have is not sufficiently generic to be acceptable for mainline and will need to be cleaned up before being submitted. In addition, there is no support for nested address spaces and that is arguably a deficiency of any implementation of this proposal. Would this be acceptable, provided that this limitation is documented? Thanks, Ben
Re: RFC: named address space support
On Thu, Apr 3, 2008 at 4:30 PM, Ben Elliston [EMAIL PROTECTED] wrote: Our implementation only covers section 5.1 of the proposal (named address space support). Section 5.2 has not been implemented. Is C++ supported? I do know for that fixed point types, C++ is mostly supported (except mangling and a couple others). I think we should not be adding extension unless they are both supported in the C and C++ front-ends. Thanks, Andrew Pinski
Re: RFC: named address space support
Is C++ supported? I do know for that fixed point types, C++ is mostly supported (except mangling and a couple others). I think we should not be adding extension unless they are both supported in the C and C++ front-ends. C++ is not supported because this proposal came from WG14 (which is not the C++ working group, WG21). There is no such proposal from the C++ folks. I don't know that implementing this right away in the C++ front-end is such a great idea. There will be plenty of proposals that come out of the C working group that are perhaps not fully considered in the context of C++. There is so much potential for unanticipated interactions in C ++ that I think we should be very cautious about implementing C extensions there just for completeness. Cheers, Ben
