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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.99.109.74 with SMTP id i71mr10515940pgc.20.1498756543274; Thu, 29 Jun 2017 10:15:43 -0700 (PDT) X-Received: by 10.36.46.202 with SMTP id i193mr399002ita.8.1498756543205; Thu, 29 Jun 2017 10:15:43 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.glorb.com!v202no60550itb.0!news-out.google.com!s132ni1844itb.0!nntp.google.com!188no126101itx.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 29 Jun 2017 10:15:42 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=2601:191:8303:2100:5985:2c17:9409:aa9c; posting-account=fdRd8woAAADTIlxCu9FgvDrUK4wPzvy3 NNTP-Posting-Host: 2601:191:8303:2100:5985:2c17:9409:aa9c References: <8e27f6c4-050d-4005-ab87-7d9981712c77@googlegroups.com> <12108259-486f-4958-b779-4814ad9a5853@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: gnat-2017 - ZFP add tasking support From: Robert Eachus Injection-Date: Thu, 29 Jun 2017 17:15:43 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:47182 Date: 2017-06-29T10:15:42-07:00 List-Id: On Thursday, June 29, 2017 at 5:09:54 AM UTC-4, alby....@gmail.com wrote: > On Monday, June 26, 2017 at 11:35:38 PM UTC+10, Mark Lorenzen wrote: > > On Monday, June 26, 2017 at 12:20:49 PM UTC+2, alby....@gmail.com wrote= : > > > On Monday, June 26, 2017 at 5:56:18 PM UTC+10, Mark Lorenzen wrote: > > > > On Monday, June 26, 2017 at 3:20:22 AM UTC+2, alby....@gmail.com wr= ote: > > > > > I was pleasantly surprised that the recent distribution of gnat-2= 017 (GPL) > > > > > included a ZFP for native platforms (mine is windows x86). And th= e project(s) > > > > > compiled cleanly, even on my personal x64 gnat build > > > > >=20 > > > > > Using this ZFP, along with my WinRT/UWP library, I was a able to = build a > > > > > simple Hello World (XAML based) that now PASSES the "Windows Stor= e app Certification". Note this is a true blue native Windows Store app, an= d does > > > > > NOT use the bridging/Centennial technology. > > > > >=20 > > > > > The main caveat in all this is, the use of the ZFP which is fairl= y > > > > > restrictive, and does not allow me to use features of Ada that I = feel would be > > > > > a must have running under this environment. In particular "Taskin= g and maybe > > > > > controlled types" > > > > >=20 > > > > > Could someone give me guidance on how to add "Tasking" support to= the ZFP ? > > > > > I can use the Mingw-64 code base, I assume its not just as simple= as adding > > > > > these source files to the ZFP source tree ? Is their any other co= nfiguration > > > > > changes needed other than in system.ads ? > > > > >=20 > > > > > Thanks > > > > >=20 > > > > > Alex > > > >=20 > > > > So you want to use the ZERO footprint run-time system, but at the s= ame time you want to use tasks and controlled types? How does this stack up= ? > > > >=20 > > > > Why don't you simply use the default run-time system? > > > >=20 > > > > Regards, > > > >=20 > > > > Mark L > > >=20 > > > Hi Mark > > >=20 > > > Apologies for the slight confusion, what I should have said/meant was= that I > > > would like to use the ZFP as a base for a new runtime profile (simila= r to > > > what AdaCore do for some of their non default run-time systems, such = as the > > > various flavours of Ravenscar and high integrity run-time systems) > > >=20 > > > And yes I could use the default run-time, but in its current form on = mingw-64 > > > its NOT certified to be distributed via "Windows Store" since it uses= parts > > > of the "C/C++" runtime that are not compatible with that environment. > > >=20 > > > So I have 2 options > > >=20 > > > 1) Start from the ZFP and add the relevant features such as Tasking > > > or > > > 2) Use the default runtime and strip out all the "Windows Store" func= tions > > > that are not compatible > > >=20 > > > I would tend to favour the second approach, but the intent of my orig= inal > > > question was to try and determine the amount of effort needed for opt= ion 1) > > >=20 > > > Please note that the central theme of incompatibles with the default = run-time > > > and "windows store" are the following > > >=20 > > > a) Store apps have no notion of a "Console" so "C" functions like pri= ntf > > > and family wont work. > > > b) "C" functions such as memcpy, memset are NOT supported in "Windows= Store" > > > c) There are some other functions in libgnat to do with exception han= dling > > > that are also NOT supported in "Windows Store" > > >=20 > > > I hope this helps in clarifying what I am trying to achieve > > >=20 > > > Thanks > > >=20 > > > Alex > >=20 > > OK that makes sense. I would definately try option 2! > >=20 > > Try and look in this document for information on restricted run-time sy= stems: http://docs.adacore.com/gnathie_ug-docs/html/gnathie_ug/gnathie_ug.h= tml You should especially check chapter 5. > >=20 > > Regards, > >=20 > > Mark L >=20 > Hi Mark and Simon >=20 > Thanks for your valued advise, Option 2) was a lot easier to implement th= an I > thought it would be. However in removing the "restricted" functions, and = I > believe this centres around the SEH (ie exception handling API's such as > RtlVirtualUnwind and RtlCaptureContext) I have inadvertently screwed up A= da's > exception handling ! >=20 > I'll try and dig deeper and analyse the issue more deeply, But if anyone = could > give me pointers on the SEH code in "raise_gcc.c", "unwind_seh.c" and > "traceback.c", that would be greatly appreciated. >=20 > Thanks >=20 > Alex Normal returns, function returns, and exception unwinding all need to disca= rd stack frames, and set the stack frame pointer and code pointers correctl= y. (Well the exception unwinding doesn't need to set the code pointer corre= ctly if the stack frame being removed did not have a handler for the except= ion. But it is better to treat getting it wrong as a bug. Bad code pointe= r values are really nasty.) What I suggest is some code that prints the two values as the first action = in any test procedure or function, print them in a when others handler that= then reraises the exception, and finally following the call. If all three= sets are identical, then test the next case. Note that you will need funct= ions which return a scalar, functions which return a record or array on the= stack, and functions that raise an exception. Procedures are easier. Tas= king? Can be a royal pain.