From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,73975695cdfcb86f X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.227.230 with SMTP id sd6mr164800pbc.8.1333567019775; Wed, 04 Apr 2012 12:16:59 -0700 (PDT) MIME-Version: 1.0 Path: r9ni18619pbh.0!nntp.google.com!news1.google.com!news4.google.com!feeder3.cambriumusenet.nl!feeder1.cambriumusenet.nl!feed.tweaknews.nl!94.232.116.12.MISMATCH!feed.xsnews.nl!border-2.ams.xsnews.nl!newsfeed.x-privat.org!news.jacob-sparre.dk!munin.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Dispatching callback handed over to C Date: Wed, 4 Apr 2012 14:16:55 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <6fb83c74-b2a4-4ae8-9c89-d755b737198f@v22g2000vby.googlegroups.com> <85d1ad51-c02b-44fa-87b6-02aa1d8ba1b2@x17g2000vba.googlegroups.com> <62246369-6b9f-4a96-9c67-fd1774c02e78@k24g2000yqe.googlegroups.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1333567018 6105 69.95.181.76 (4 Apr 2012 19:16:58 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Wed, 4 Apr 2012 19:16:58 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Date: 2012-04-04T14:16:55-05:00 List-Id: "Maciej Sobczak" wrote in message news:62246369-6b9f-4a96-9c67-fd1774c02e78@k24g2000yqe.googlegroups.com... > On 3 Kwi, 22:20, "Randy Brukardt" wrote: > >> The basic idea is that System.Address ought to be able to access any >> memory >> on the target that might have hardware located at it. > > Interestingly, this is also the intent of void*. But that's impossible. In general, data memory and code memory are different things and require different access. They are totally separated in Janus/Ada, with separate code pointer and data pointer types. (Some targets map these as the same, of course, but many don't.) An additional concern is callability: code pointers have enough information to support calls, and data pointers don't. (In particular, the U2200 hardware requires a static link as part of a code pointer. You can't call a bare address under any circumstances.) void * is a data pointer, and ought to be treated that way. It is not necessarily going to have access to the code of a program (nor should there be any need to access the code from an data pointer). System.Address, OTOH, does need access to the code portions and that often will require a different, larger representation. >> Matching the C compiler is irrelevant; we have access >> types and convention C for that purpose > > This is almost true. > The problem is that AARM gives no provisions whatsoever to pass access > to class-wide types (only types that have "corresponding C types" are > covered) to or from C and the ability to do it seems to be essential > in the OO context. That is, there is no direct way to be standard- > compliant here. It doesn't even make sense to pass "access-to-class-wide types" to C (as opposed to C++). C doesn't know what to do with them. > Note that in my solution the access to class-wide is passed to C++ and > back only for storage - the actual use (the dispatching call) is at > the Ada side, so the mechanics used for that storage need to only > ensure that the physical representation of access value is retained. > System.Address with void* do it properly on my platform. > Using a string representation might be a possible solution, too, even > if potentially slower. If all you want to do is store them, just stick them in the record as "access-to-class-wide" and don't even worry about having a C counterpart. You need some c-compatible type in the C-side, but it is just a "bucket-of-bits". For instance, that's how we find the Ada object in Claw; we unchecked-convert access-to-class-wide to a DWord in Windows, and then when we need to use it, we unchecked-convert back. If I needed to make this totally portable and had sufficient control over the API, I'd replace the DWord by a locally-declared modular type of which I could control the size to match the target. But there is little point in going further than that. > That it does not work on your compiler? > Count it as my feature request, then. ;-) System.Address is the wrong type to use for a "bucket-of-bits". I agree that it would be nice to be able to directly put the access-to-class-wide in the C convention record (and most compilers will in fact allow this, after giving some warnings), but it doesn't seem to make that much difference. Randy.