3

I am researching the development of a lisp compiler which targets embedded devices (16KB or so of RAM) and low level systems programming (i.e. Kernel modules), both of which necessitate complexity guarantees and access to low level constructs.

Even though I need these constructs, I don't want the language to be "low level", in that I want to provide the user with high level constructs which still deliver low level guarantees (I.e. Lisp macros, support for aspect oriented programming, logic or constraint solving, and functional paradigms, etc.).

My current train of thought is that I need to:

  • Create a thin wrapper of s-expression syntax over C99
  • Write macros that define higher levels of abstraction, while still exposing low level structs, pointers, etc.
  • Feed resultant C99 code into gcc, and get the binary I will run

I want to know if my reasoning is sound on this - would the code generated by such a process be able to operate with such a small memory footprint? I don't intend the language to have a runtime component.

Lundin
  • 195,001
  • 40
  • 254
  • 396
bmuk
  • 121
  • 5
  • 3
    Sorry, this is off-topic. You might want to look at [Stalin](https://github.com/barak/stalin) for an example of such compiler. [Matt Mights home page](http://matt.might.net/articles/compiling-scheme-to-c/) and the [90 minute Scheme compiler](http://churchturing.org/y/90-min-scc.pdf) are relevant for you though. Happy hacking! – Sylwester Apr 15 '15 at 00:30
  • 3
    You might look at PicoLisp: http://software-lab.de/doc/ref.html – chqrlie Apr 15 '15 at 00:54
  • 1
    Also note that there's a big difference between a *compiler that targets a constrained environment* and a *compiler that can run in a constrained environment*. You could compile lots of Common Lisp for a very small system, and if you exclude some of the more dynamic aspect, you could make it very small, too. – Joshua Taylor Apr 15 '15 at 03:15
  • 1
    The main question is not off-topic, just the additional one about recommendations. I'll take the liberty to edit out that part, so the question won't get closed for that reason. The question may still be too broad but I know too little of the topic to tell. – Lundin Apr 15 '15 at 09:12
  • 1
    @Lundin: the question makes not much sense. 16kb memory, a high-level language with all kinds of paradigms, a Lisp compiler, but really only a thin wrapper over C99, no runtime component, ... then the question: 'would it operate in 16kb'? How should anyone know that? – Rainer Joswig Apr 16 '15 at 11:20
  • @Rainier: I apologize for not having a more specific question. My concern is that there's something I'm missing - maybe these features necessitate more overhead? I also don't think I was clear enough about what I intend to do. The wrapper around c99 would be the core, and I would write macros that transform that core, giving me whatever features I need. – bmuk Apr 16 '15 at 23:01
  • The problem is that you haven't specified what *exactly* "these features" are, or what kind of code you intend to write with them. There is no real answer to the question in its current form beyond "yeah, probably". Some of the hinted features also have multiple styles of implementation that would radically affect the answer (e.g. AOP can be compile-time *or* runtime, with different implications). – Alex Celeste Apr 17 '15 at 00:32
  • OK, let's say the features are closures, macros, and tail call optimization. – bmuk Apr 17 '15 at 00:44
  • Everything should be compile time only, the aspect orientation included. – bmuk Apr 17 '15 at 00:55
  • Well, if you say they're compile-time only, then they're compile-time only and have no overhead. Lisp macros allow you to extend the language in *arbitrarily complex* ways: any semantic that can be implemented by a compiler can be implemented by Lisp macros too. So you literally can do whatever you have a clear idea of and the patience to implement (do you have a clear idea about what "compile-time closures" means for your language?). – Alex Celeste Apr 17 '15 at 01:08
  • Sure, but what I'm asking is will these macros add a lot of overhead? They get translated at compile time, sure, but how do I ensure they generate efficient c code? – bmuk Apr 17 '15 at 03:59

2 Answers2

1

Dale is C (/a C-like language), but written with Lisp's syntax and several high-level compile-time features (macros, type inference, anonymous functions, modules... nothing that impacts runtime).

PreScheme is the same destination reached by working from the opposite direction: it is a restricted dialect of Scheme that removes those runtime features that can't be translated 1:1 into C (such as continuations, general tail calls, GC, runtime dynamic typing). PreScheme continues to support Scheme runtime features at the top-level, because this can be moved to "compile time". PreScheme is part of Scheme48 and is used to implement its runtime.

Alternatively, where the main concern is space but not necessarily bare-metal performance, it is often easier to crunch an interpreter down to very small sizes; PICOBIT ([1], [2]) is designed to run in <7Kb while providing a pretty complete Scheme implementation.

Alex Celeste
  • 12,824
  • 10
  • 46
  • 89
0

I think that you may visit cliki in the section implementations:

Common+Lisp+Implementation

After that I recommend you ECL

embeddable-common-lisp

And I also recommend you this book, Build Your Own Lisp, which teach you how to build an entire Lisp environment with C, book link

anquegi
  • 11,125
  • 4
  • 51
  • 67