Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
L ldpl
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 8
    • Issues 8
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI/CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Lartu
  • ldpl
  • Merge requests
  • !36

Merged
Created Apr 04, 2019 by Lartu@lartu🐕Maintainer

Experimental support for C++ extensions

  • Overview 17
  • Commits 17
  • Changes 7

Created by: dvkt

Hi, my boss is making me rewrite our cryptocurrency platform using LDPL and so I need to be able to write custom subroutines in C++ and access them from my LDPL programs. For performance reasons.

This branch adds basic C++ extension support to the compiler for mac & linux. It's probably not the way it should be done, but I thought maybe it could start a discussion at least.

Have you thought about how this should work? I'm sure people want to write games and voting machines and all sorts of things in LDPL.

"Extensions" according to this branch are .a static archives accompanied by an.h file that can contain C++ functions and variables which can be called from LDPL as if they were subprocedures and text/number/vector variables.

For example, this LDPL code:

STORE "cool" IN temp
CALL weather

Could be calling a C++ function that looks like:

void SUBPR_WEATHER()
{
    cout << "weather is: " << VAR_TEMP << endl;
}

The glue is the extension's .h file, which needs to declare which variables and functions it's using:

extern string VAR_TEMP;
void SUBPR_WEATHER();

The ldpl compiler will look at the .h file to figure out what variables and subprocedures are in the extension's .a archive file. It uses that information to let you work with those variables and subprocedures as if they were defined in LDPL code.

Building instructions are in the README.md in examples/cpp-extension, but basically you just create an .o file for each .cpp and .h file you have, then pack those into an .a file with ar:

$ c++ -c my-ext.cpp -std=gnu++11 -o my-ext.o
$ ar -cvq my-ext.a my-ext.o

To build an LDPL program that uses my-ext.a, pass my-ext.h to -i=:

$ ldpl -i=my-ext.h program.ldpl

Both my-ext.h and my-ext.a must be in the same file as program.ldpl, and my-ext.a must be built for the current architecture.

I have an example extension at https://github.com/dvkt/ldplnoise which wraps linenoise.hpp, allowing for an ACCEPT prompt that has some readline features like up/down history. I've only tested it on macos and arch linux so it could be riddled with bugs still.

Anoter simpler example is at https://github.com/dvkt/hi-c

There's also the simplest example in this branch at examples/cpp-extension. It has a Makefile which will build a version of ldpl specific to this branch to test it. And that README I mentioned.

Code

Most of the code is in the ldpl compiler in the code for handling -i= flags. If a .h file is passed, ldpl will look for a .a file and then include that when building the final compiled program. It'll also parse the lines of the .h file to figure out what variables and subprocedures are in the extension.

Problems

  • Mac/Linux only, and I've only tested on Arch Linux and MacOS Mojave.
  • Not sure how you envision the syntax. I just reused what was existing.
  • Requires building .a for the extension using c++ and ar. Maybe it could be automated to be easier for extension authors.
  • Requires both an .a file and a .h file to use an extension in LDPL code.
  • Requires parsing a .h file in C++, which is gonna be brittle.
  • I'm not sure if you even want LDPL to ever do this kind of stuff!
  • Depends directly on LDPL's internal name wrangling format for variables and subprocedures which makes the var/sub names kinda nasty if you want to use - / . etc.
  • Probably lots of bugs, did I mention that.
  • No way to use ldpl_number or the vectors without declaring the prototypes yourself, which is what I do in the hi-c example.
  • No clue how this will work with dynamic libraries, or if it even can.
  • My C++ is bad.
  • …

Anyway curious to hear how/if you think extensions should work in LDPL. And let me know if I left anything out / what I screwed up thanks!

Assignee
Assign to
Reviewer
Request review from
None
Milestone
None
Assign milestone
Time tracking
Source branch: github/fork/dvkt/extensions