Least Dangerous Way to Do This ?

Least Dangerous Way to Do This ?

[patrick]

Hi Everyone

Okay, don't laugh(or laugh too hard)

I need to interface with automatically generated C. function pointers are represented as a pointer to a pointer to a char. This is weird but done for pointer arithmetic purposes.

I have this:

type pointer1  is access character ;
type pointer2 is access pointer1 ;
foo : pointer2 ;

What do you think is the best way to assign an access to a subprogram to foo ?

I realize this is really-really weird and dangerous which is why I am asking for help.

-Patrick

Re: Least Dangerous Way to Do This ?

[patrick]

sorry to reply to my own post.

Here is some C I am trying to redo in Ada:

int init_obj(char **test_ptr){
  (*test_ptr) = (char *)&foo ;
}

or in a struct/record, this is obviously just hacky code to try something out

typedef struct _obj 
{
int intty ;
char **procedure_pointer ;
} obj ;

int foo(int nothing){
 printf("this is foo in C \n")  ;
}

int init_obj(obj *obj_test){
  obj_test->intty             = 4 ;
  obj_test->procedure_pointer = (char **)&foo ;
}

Re: Least Dangerous Way to Do This ?

[Jacob Sparre Andersen]

patrick@spellingbeewinnars.org writes:

> I need to interface with automatically generated C.

Have you tried to see how a binding generated by `gcc -fdump-ada-spec`
(or `g++ -fdump-ada-spec`) looks?

Greetings,

Jacob
-- 
There really was only one way to make a person unlearn something ...

Re: Least Dangerous Way to Do This ?

[Simon Wright]

patrick@spellingbeewinnars.org writes:

> I need to interface with automatically generated C. function pointers
> are represented as a pointer to a pointer to a char. This is weird but
> done for pointer arithmetic purposes.

But it's not really a char**, is it!

   procedure Pointers is
      type Procedure_P is access procedure with Convention => C;
      type Procedure_P_P is access Procedure_P;
      P : Procedure_P_P;
      procedure Proc is null with Convention => C;
   begin
      P.all := Proc'Access;
   end Pointers;

You could try something involving Proc'Address, though it's not obvious
that that's mandated to be the address of something that you could
call. Maybe convention C does that.

Re: Least Dangerous Way to Do This ?

[patrick]

Thanks Jacob and Simon !

This is proving to be quite tricky. I have the pointer stuff worked out but I have memory access errors. I will figure this out. If this works out, I will post to the mailing list, I think you will find it interesting or laughable :)

-Patrick

Re: Least Dangerous Way to Do This ?

[patrick]

Okay, I worked through the last piece. You know what I am doing.....

I am thinking about using the Ada.XXX and Gnat.XXX libraries from GnuCOBOL !

Hee-hee, I know COBOL isn't going to have a lot of fans here but it is actually a lot of fun.

I will post back with some examples just in case someone cares :)

Re: Least Dangerous Way to Do This ?

[Randy Brukardt]

<patrick@spellingbeewinnars.org> wrote in message 
news:beac86f1-fa15-4719-bfc3-8d0334260906@googlegroups.com...
> Hi Everyone
>
> Okay, don't laugh(or laugh too hard)
>
> I need to interface with automatically generated C. function pointers are 
> represented as a pointer to a pointer to a char. This is weird but done 
> for pointer arithmetic purposes.

It's not certain (in the real world, at least) if a function pointer and an 
object pointer have the same representation. We treat them as completely 
different things in our code generator, because some weird machines (in 
particular the U2200) have very large representations for function pointers 
(one version was 8 36-bit words!). Similarly, on the 16-bit 8086 compilers, 
function pointers carried a segment (thus a 32-bit address), and object 
pointers usually didn't (thus a 16-bit address).

So if you want this code to work in different environments, I'd try to avoid 
mixing the two (as Simon suggested).

                                                  Randy.

Re: Least Dangerous Way to Do This ?

[Shark8]

On Monday, October 15, 2018 at 1:36:09 PM UTC-6, pat...@spellingbeewinnars.org wrote:
> Okay, I worked through the last piece. You know what I am doing.....
> 
> I am thinking about using the Ada.XXX and Gnat.XXX libraries from GnuCOBOL !
> 
> Hee-hee, I know COBOL isn't going to have a lot of fans here but it is actually a lot of fun.

Ada has a whole section in Annex B for interfacing to COBOL -- "B.4 Interfacing with COBOL" -- online here: http://www.ada-auth.org/standards/2xrm/html/RM-B-4.html

Exporting to COBOL will be as easy as saying:
  Function J return Integer
    with Export, Convention => COBOL;

And Importing is similar:
  Function K return Interfaces.COBOL.Floating
    with Import, Convention => COBOL;

Actually given Ada's ease with interfacing like this, and the SPARK provers, I'm surprised that the banking industry hasn't leveraged Ada into its infrastructure, using Ada to prove the correctness of the system and COBOL for the fast reporting/record-processing as-needed.

> 
> I will post back with some examples just in case someone cares :)

I think that would be pretty cool.

Re: Least Dangerous Way to Do This ?

[patrick]

Thanks Randy

GnuCOBOL has 2 types, procedure-pointer and pointer. 

I would have to dig into the generated C to tell you for sure how they differ but I think I should be safe.

GnuCOBOL runs on pretty much anything that has an OS from Raspberry PIs to Z Series mainframes so I think that this is a concern that has been addressed.

-Patrick

Re: Least Dangerous Way to Do This ?

[patrick]

Hi Shark8

I am actually pretty familiar with the interface to cobol package. I actually don't trust it. I am thinking about trying to improve it but in it's current condition, it could be a liability.

So Ada83 was pretty cool already but if we had Ada68 or Ada78 they would have sucked large. COBOL68 and COBOL73 suck and the language is still haunted by criticism from this time.

When I first started with GnuCOBOL(called Open-Cobol at the time) I thought it was awesome and that the critics must all be insane and then I saw code from 68 and 73 revisions. One program(like a procedure) was almost 10000 lines long. All identifiers were limited to 8 characters. There was not a single comment in it. So yes old COBOL is terrible. The thing is that the interfaces cobol package appears to be for this old code and not the current stuff.

In COBOL we have pointers, procedures(called programs) and functions. The spec file in the interfaces cobol package makes all kinds of false statements.

GnuCOBOL generates intermediate C, so I can inspect it and see what is happening. At the moment I am better off with the interfaces C package.

I have wondered the same thing. People can write very reliable COBOL code but there are some topics related to calling other procedures(programs) that could be a concern for the most critical portions, this is where Ada would really shine in banking, yet it doesn't.

Ada has much better facilities for organizing huge amounts of code yet COBOL likely has far larger code bases. I think one bank has something like 130 million lines of COBOL, I could borrow the library book I read this in, to get the exact amount if your interested but the point is that organizing this much code in COBOL is very hard.

I hope you don't mind a bit of a rant but I think Ada has serious-serious advocacy issues. Adacore has done a horrible job and we could improve more as a community too. Catering to existing Adacore customers does not move the language forward. Adacore did not move to microcontrollers for the longest time and it has staff that go around telling people not to use Ada for webservers or telephony systems when this would actually be good things to do and so on.

People using Ada for fun like on AVRs and on the Raspberry Pi are doing good work. We really need to show people what can be done with it and done with it for fun.

Books are terrible. You can read hundreds and hundreds of pages were all that is being demonstrated is some language feature you are never going to use and text_io displaying something. I have 53lbs of Ada books(and counting) and in all this I think I have 2 or 3 pages that deal with interfacing with real hardware and there is next to no information about interfacing with other languages. How many new application these days are going to be in pure Ada, it's crazy to cover features from Ada2005 and Ada2012 and not providing any examples of interfacing with other languages. What are you actually going to do with interfaces in a new code base that has no contact with other languages ? isn't it more important to understand procedures, function and packages and how to use Ada with other languages?

Today is a special day for me. I realized something super-awesome about Ada that no one told me about and that I did not read about and this really should not have happened. It's so simple in hindsight but I didn't realize that you could use Ada packages with other languages without "with"ing them into an Ada program. I patched byteswap with pragma export and called it from COBOL. I can now use an Ada library directly from COBOL without writing any Ada code. Fortran and C people could do the same, with some simple patching.

So I can't verify that any of this is true but according to MicroFocus, a company with a vested interest in COBOL(and that sued a city here in Canada for having too many copies of their software) the cost to replace COBOL in the USA would be over 1 trillion. They say that there is hundreds of billions of lines of code in use. Others have said that there is more COBOL code than all other languages combined. Again, I am not saying that all of this is true, it could be fanboy propaganda but certainly there is mountains of it.

Please see this site(it is a lot of material on one page and can be slow to load):
https://open-cobol.sourceforge.io/faq/index.html

This will give a good overview of the language. There is a small part that touches on Ada. However look at this code, it's almost all using C libraries. GnuCOBOL has lots of facilities for interfacing with C, especially matching types but we still have to jump though some hoops such as appending nul bytes and so on.

Ada and COBOL are much closer then COBOL and C and Ada has tons of facilities for working with other languages, such as it's type system and strings.fixed to match COBOL's and so on, they are just poorly documented.

I am planning on patching as many Ada libraries as I can so that they can be used from GnuCOBOL. There is so much functionality that we don't have in our community. Imagine if this ends up being used by existing COBOL code bases... Maybe even banks will see the value if I can do this, I write up lots of documentation and I can actually try to promote these concepts.

If one company is entrusted to promote Ada and all they want to do is service existing customers, the language will die out when there old customers finally switch to C++/Java etc..

There is so much to promote and so much value to be had but Ada instruction books and Adacore are not going to get the word out, we need to !

Re: Least Dangerous Way to Do This ?

[Petter Fryklund]

> > Hi Everyone
> >
> > Okay, don't laugh(or laugh too hard)
> >
> > I need to interface with automatically generated C. function pointers are 
> > represented as a pointer to a pointer to a char. This is weird but done 
> > for pointer arithmetic purposes.
> 
> It's not certain (in the real world, at least) if a function pointer and an 
> object pointer have the same representation. We treat them as completely 
> different things in our code generator, because some weird machines (in 
> particular the U2200) have very large representations for function pointers 
> (one version was 8 36-bit words!). Similarly, on the 16-bit 8086 compilers, 
> function pointers carried a segment (thus a 32-bit address), and object 
> pointers usually didn't (thus a 16-bit address).
> 
> So if you want this code to work in different environments, I'd try to avoid 
> mixing the two (as Simon suggested).
> 
>                                                   Randy.

I don't think the U2200 is weird, it is or was actually a very nice machine. Unfortunately most of the Unisys Linköping people where kicked out before we could try Ada, but we where very interested in it then. I for a while maintained the local releases of COBOL before going in to performance analysis and cache-disk simulations.

Is there any U2200 out there? comp.sys.unisys talks a lot about virtual ones.

Regards,
Petter

Re: Least Dangerous Way to Do This ?

[Shark8]

On Tuesday, October 16, 2018 at 6:09:49 PM UTC-6, pat...@spellingbeewinnars.org wrote:
> Hi Shark8
> 
> I am actually pretty familiar with the interface to cobol package. I actually don't trust it. I am thinking about trying to improve it but in it's current condition, it could be a liability.
> 
> So Ada83 was pretty cool already but if we had Ada68 or Ada78 they would have sucked large. COBOL68 and COBOL73 suck and the language is still haunted by criticism from this time.
> 
> When I first started with GnuCOBOL(called Open-Cobol at the time) I thought it was awesome and that the critics must all be insane and then I saw code from 68 and 73 revisions. One program(like a procedure) was almost 10000 lines long. All identifiers were limited to 8 characters. There was not a single comment in it. So yes old COBOL is terrible. The thing is that the interfaces cobol package appears to be for this old code and not the current stuff.

Interesting.

> 
> In COBOL we have pointers, procedures(called programs) and functions. The spec file in the interfaces cobol package makes all kinds of false statements.

I'm rather looking forward to seeing your improved COBOL interface.
(We might even be able to replace Interfaces.COBOL, or perhaps add a new child-package like Interfaces.COBOL.ISO_1989_2014.)

> 
> GnuCOBOL generates intermediate C, so I can inspect it and see what is happening. At the moment I am better off with the interfaces C package.

Hm, are you going to use that as a bit of a feedback-loop in your design of a [new] COBOL interfacing package?
 
> I have wondered the same thing. People can write very reliable COBOL code but there are some topics related to calling other procedures(programs) that could be a concern for the most critical portions, this is where Ada would really shine in banking, yet it doesn't.
>
> 
> Ada has much better facilities for organizing huge amounts of code yet COBOL likely has far larger code bases. I think one bank has something like 130 million lines of COBOL, I could borrow the library book I read this in, to get the exact amount if your interested but the point is that organizing this much code in COBOL is very hard.

Indeed, and code-organization is one area that Ada really shines [IMO].

> 
> I hope you don't mind a bit of a rant but I think Ada has serious-serious advocacy issues. Adacore has done a horrible job and we could improve more as a community too. Catering to existing Adacore customers does not move the language forward. Adacore did not move to microcontrollers for the longest time and it has staff that go around telling people not to use Ada for webservers or telephony systems when this would actually be good things to do and so on.

I'm not bothered by your rant -- it actually mirrors a lot of the criticisms the Ada-community as-a-whole has. While I'm glad that AdaCore has interests in Ada, and does some good work, there are some big problems that "only one [viable, opensource] implementation" entails which isn't good for the language as-a-whole.

> 
> Books are terrible. You can read hundreds and hundreds of pages were all that is being demonstrated is some language feature you are never going to use and text_io displaying something. I have 53lbs of Ada books(and counting) and in all this I think I have 2 or 3 pages that deal with interfacing with real hardware and there is next to no information about interfacing with other languages. How many new application these days are going to be in pure Ada, it's crazy to cover features from Ada2005 and Ada2012 and not providing any examples of interfacing with other languages. What are you actually going to do with interfaces in a new code base that has no contact with other languages ? isn't it more important to understand procedures, function and packages and how to use Ada with other languages?

Interesting critique.
I've heard it said that the problem is that there's no "entry/introductory level" books, rather than books as-a-whole.

> 
> Today is a special day for me. I realized something super-awesome about Ada that no one told me about and that I did not read about and this really should not have happened. It's so simple in hindsight but I didn't realize that you could use Ada packages with other languages without "with"ing them into an Ada program. I patched byteswap with pragma export and called it from COBOL. I can now use an Ada library directly from COBOL without writing any Ada code. Fortran and C people could do the same, with some simple patching.

Hm?
Are you referring to simply compiling a package and linking to the resultant OBJ file? Or am I misunderstanding you?

> Please see this site(it is a lot of material on one page and can be slow to load):
> https://open-cobol.sourceforge.io/faq/index.html
> 
> This will give a good overview of the language. There is a small part that touches on Ada. However look at this code, it's almost all using C libraries. GnuCOBOL has lots of facilities for interfacing with C, especially matching types but we still have to jump though some hoops such as appending nul bytes and so on.

Interesting, I'll take a look.

> 
> I am planning on patching as many Ada libraries as I can so that they can be used from GnuCOBOL. There is so much functionality that we don't have in our community. Imagine if this ends up being used by existing COBOL code bases... Maybe even banks will see the value if I can do this, I write up lots of documentation and I can actually try to promote these concepts.
> 

I, for one, would love to see this.
There's a lot of value to be had here: keeping your main-system organized, proven (where possible), and ensuring that your main reporting/processing isn't being handed garbage is a big win.

> If one company is entrusted to promote Ada and all they want to do is service existing customers, the language will die out when there old customers finally switch to C++/Java etc..

Yep.
This is a big problem, in part because existing customers develop work-arounds for flaws and issues that they never voice (that's just how things are), whereas new customers will have different needs and ideas [and expectations] which often at least shed some light on issues.

> 
> There is so much to promote and so much value to be had but Ada instruction books and Adacore are not going to get the word out, we need to !

I try.

Re: Least Dangerous Way to Do This ?

[Randy Brukardt]

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

"Petter Fryklund" <petter.fryklund@atero.se> wrote in message 
news:63bee5dc-51c0-4092-8e46-69e0301f1427@googlegroups.com...
...
>I don't think the U2200 is weird, it is or was actually a very nice 
>machine.

Well, the actual machine code is very weird; it was weird enough that they 
provided our project with a guy whose main job was to figure out what was 
happening at the lowest level and feed it back to the rest of us working in 
the "normal" world.

>Unfortunately most of the Unisys Linköping people where kicked out
>before we could try Ada, but we where very interested in it then. I for a
>while maintained the local releases of COBOL before going in to
>performance analysis and cache-disk simulations.

So far as I know, no one ever used the Ada 95 compiler we built for Unisys. 
(I hope not, 'cause we never got paid for one. :-) It was a lot harder 
project than we predicted and it didn't get done fast enough for the 
prospective customers. A very interesting project, though.

>Is there any U2200 out there? comp.sys.unisys talks a lot about virtual 
>ones.

Dunno. I haven't heard from any of that group in many years.

                                         Randy.

Re: Least Dangerous Way to Do This ?

[Petter Fryklund]

> Well, the actual machine code is very weird; it was weird enough that they 
> provided our project with a guy whose main job was to figure out what was 
> happening at the lowest level and feed it back to the rest of us working in 
> the "normal" world.

I regard(ed) 1100/2200 as the normal world ;-), it is (was) everything else that is weird. For instance, until much later I didn't know about little-endian, still weird to me. I was almost brought up with 1100, since I got head-hunted together with 27 other people directly from University. 

Traditional machine-code like early 1100 is very nice. I love traditional LMJ, Load Modifier and Jump, which loaded the return address in the modifier part of a X (index) register and jumped to the specified location. The called routine could then return to an offset of the X register where 0 was usually the normal return and others different error returns. The X register could also do automatic increments and decrements when used. The Modifier part was added to the other part if a bit in the instruction was set. We needed all 36 bits of the instructions for different purposes including part-word operations. The ability to have for different banks directly visible (maybe later there where more?) and possibility to change any of them with just one or two instructions was very neat. Those where the days.

I agree that the new what-ever-it-was-called, I bet new, was a bit ..., but not weird ;-) 

But 1991 I "had" to learn Ada, which I have used most of the time since. 

Regards,
Petter 

Re: Least Dangerous Way to Do This ?

[patrick]

Hi Shark8

Thanks very much. I am going to start another thread tonight about GnuCOBOL and Ada. This thread has drifted quite a bit.

Be back soon