Shop OBEX P1 Docs P2 Docs Learn Events
GNU Cobol for P2 — Parallax Forums

GNU Cobol for P2

@msrobots , you mentioned in another thread that you'd like to get this working. Do you have an actual program you wanted to try? The translated C code probably will compile with riscvp2, and might even compile with Catalina or fastspin. It's worth giving it a go :)

Comments

  • Well Eric, the problem is that the whole GnuCOBOL system and the developers are very LINUX centric and I am not.

    The basic concept is that COBOL source gets transpiled to C code (not c++) and then compiled with usually GCC. But accepts lots of different compilers. Even Visual Studio on Windows so it does not need a complete POSIX just some of it, I am guessing here.

    My basic hurdle here is that the created files need some runtime library support and I was not able to figure out how to static link all needed files.

    You have now SD-card routines, how about overlays from disk? There was a thread where somebody managed that with PropGcc and a changed linker script since GCC still supports the DOS without extended memory overlay model.

    As far as I got I need something like dll support. But I actually do have a quite hard time to read AND understand the generated C sources, they are not made to be read by humans, compilers should read them.

    GnuCOBOL has a very friendly and helpful forum quite alike this forum here but, I fail completely to understand the required process to cross compile because of none LINUX experience.

    My current hope for COBOL on P2 is @Cluso99, I have two different COBOL compiler binaries for Z80 and CP/M. Both sadly failed on the P1 CP/M.

    But like you said it might just work with riscp2 if I could figure out how to do that. As far as I know GnuCOBOL supports a lot of different architectures, Z/OS, SUN, SPARK, ARM, X86 LINUX/WINDOWS and there was some claim that someone got it to run on some PICXXX.

    What I AM sure about is that COBOL on the P2 would be wonderful. SCREEN Sections to define displays, REPORT sections to define printouts or mailouts. ISAM file support, it's all there since 1960 or so.

    I do know that you are quite buys but a FlexCOBOL would be very cool...

    Enjoy!

    Mike
  • ElectrodudeElectrodude Posts: 1,657
    edited 2020-09-09 02:48
    Is this so you can run all your banking software on the P2? Aren't other processors designed for sequential computation and not bit-banging better suited for such applications?
    msrobots wrote: »
    SCREEN Sections to define displays, REPORT sections to define printouts or mailouts. ISAM file support, it's all there since 1960 or so.

    Any other language can do these things just fine.
  • msrobots wrote: »
    The basic concept is that COBOL source gets transpiled to C code (not c++) and then compiled with usually GCC. But accepts lots of different compilers. Even Visual Studio on Windows so it does not need a complete POSIX just some of it, I am guessing here.

    My basic hurdle here is that the created files need some runtime library support and I was not able to figure out how to static link all needed files.

    You have now SD-card routines, how about overlays from disk? There was a thread where somebody managed that with PropGcc and a changed linker script since GCC still supports the DOS without extended memory overlay model.

    I doubt you'll need overlays or dlls, you should be able to statically link everything for the P2 (which has 512K of memory). riscvp2 is a complete GCC compiler, so it could certainly compile everything. The only question is whether the library support will be complete enough to run. riscvp2 uses newlib, which is a fairly complete C library except that disk I/O isn't supported.

    You'd have to compile libcob and the other support libraries into .a (static library) files, and then include those on the command line of the final build.

    But if you're not comfortable with C programming this may be quite a hurdle. It won't be plug and play.
    I do know that you are quite buys but a FlexCOBOL would be very cool...

    I rather think that you would be the only customer!
  • Where do you all get your ideas from? Cobol on a microprocessor? But don’t listen to me, I’m just envious of you :smiley:
  • ersmith wrote: »
    msrobots wrote: »
    The basic concept is that COBOL source gets transpiled to C code (not c++) and then compiled with usually GCC. But accepts lots of different compilers. Even Visual Studio on Windows so it does not need a complete POSIX just some of it, I am guessing here.

    My basic hurdle here is that the created files need some runtime library support and I was not able to figure out how to static link all needed files.

    You have now SD-card routines, how about overlays from disk? There was a thread where somebody managed that with PropGcc and a changed linker script since GCC still supports the DOS without extended memory overlay model.

    I doubt you'll need overlays or dlls, you should be able to statically link everything for the P2 (which has 512K of memory). riscvp2 is a complete GCC compiler, so it could certainly compile everything. The only question is whether the library support will be complete enough to run. riscvp2 uses newlib, which is a fairly complete C library except that disk I/O isn't supported.

    You'd have to compile libcob and the other support libraries into .a (static library) files, and then include those on the command line of the final build.

    But if you're not comfortable with C programming this may be quite a hurdle. It won't be plug and play.
    I do know that you are quite buys but a FlexCOBOL would be very cool...

    I rather think that you would be the only customer!

    Maybe. It is just that I still like COBOL because of its longlivity(?) of the source code. I just had some Job to work on some source started in 1972 and was able to test it with GnuCobol on Windows, run it under MVS in Hercules and the same Code got deployed under Z/OS on a quite current IBM mainframe.

    I just worked on the COBOL side so have no clue at all how to do all of the deployment stuff, all was set up for me to use, and besides shaving, a suit and a tie I was not at all allowed to bring laptop, cellphone or even have internet access.
    Is this so you can run all your banking software on the P2? Aren't other processors designed for sequential computation and not bit-banging better suited for such applications?
    msrobots wrote: »
    SCREEN Sections to define displays, REPORT sections to define printouts or mailouts. ISAM file support, it's all there since 1960 or so.

    Any other language can do these things just fine.

    I doubt that very much. COBOL was designed to do batch processed transactions very fast with hardware quite slower as even a Iphone 1. And it still does that. For example we have about 1 billion ATM transactions per day in the US and what language is used? Just guess.

    What do you think produces your AT&T telephone bill? Insurances? Banks? Stock Market? Airlines? Everywhere where you need to run a lot of transactions
    constant without interruption you find some Mainframe and COBOL.

    And a lot of that code is OLD, hundreds of thousands of man years worldwide, Running since 50+ years, the original programmers are not retired, they died decades ago. But the code still runs and is maintainable even after decades of not looking at it.

    It is the most wordy language I ever programmed in, but on the other hand it is almost readable English, so one does not need much comments to follow the intent.

    And it offers so much of formatting options you will bite your teeth out with prinf() or equals. Sure mostly designed for text terminals connected serial like the P2 could do perfectly?

    @Cluso99 has CP/M running on the P2 experimental and I hope he stays on it, because MP/M with bank switching could work nice and we even would have a basic network all without any PC/Windows/Linux/Cellphone.

    IMHO we need to go back to the basics, having a P2 Terminal Screen, Keyboard, Mouse, SD and able to display Chips debug screens. Could also be able to program connected other P2's.

    But back to COBOL on the P2 it is just a wonderful language to describe the layout of a TEXT screen, including formatting for numbers to display, able to accept (basically) fields like in a web page and put them in normal variables, the formatting stuff happens in the output screen.

    It was build for very limited machines and basic(?) user interaction but mainly used for batch processing of fast moving data.

    Exactly what one needs on a Microcontroller, fast batch processing on some cores and a simple user interface on one core?

    Anyways, programming C# for a living normally and fighting with Windows and VS updates every year I REALLY enjoyed the COBOL experience again.

    Mike
  • If we were to implement Tektronix mode on a P2 terminal, a lot of basic graphics can be done and overlayed right over text.

    Maybe do a super set of it, like Chip just showed off.

    Re: COBOL

    I really like code that endures. I have some CAD stuff I wrote in like 91. Stayed away from complexity, stuck with basics. Still in use today on much newer editions of that system. Many other utilities broke with the times.

  • TorTor Posts: 2,010
    edited 2020-09-10 07:16
    COBOL was designed and implemented for, and on, computers so resource limited that it makes my SD card look like a supercomputer (yes there's CPU power there). A P2 would look like inifinite power to the designers of COBOL. And, as COBOL is essentially unchanged since then *of course* it makes sence to target a (any!) microcontroller. I for one applaud msrobots for sticking with it, even if I'll probably never write any COBOL myself.
Sign In or Register to comment.