5

Our company has a legacy assembly-like language with some terrible design choices. I'm pretty sure the language is not going to change, since way too many legacy things might change their behavior which would be obviously unintended.

I'd like to use/find any language which has at least C-like syntax ( or something similar, just make it not exotic, like LISP or so :) ) Only basic elements are needed, for example:

  • functions
  • local variables
  • basic operators (bitwise, basic math)
  • Comments

    • NO global variables exists

No OOP or anything special is necessary. I don't want to actually run that piece of code, I just want to use a decent syntax, which during a "compilation" is converted into that ugly assembly-like (asm would be at least organized, but it's worse) language.

What can you recommend me to start looking at? If not necessary I wouldn't like to write my own parser for this. I'm good at C++, but any language is okay if it better suits my needs.

  • 3
    You'd be looking at either writing an interpreter or writing something that can take an intermediate language and convert it into your assembler. For example, maybe writing a custom LLVM backend? Then you could compile C to LLVM intermediate code and then translate that. I'm not really sure how that all works, however. – Alex Hart Jul 16 '19 at 14:56
  • 1
    Why not just use C? GCC supports assembly output. – Robert Harvey Jul 16 '19 at 15:04
  • 1
    I agree with @AlexHart's approach. LLVM already has support for C, including all of the parsing, lexing and creating an IR representation, so all you would have to do is write the backend that produces your homegrown representation. LLVM has already done most of the heavy lifting for you. – Robert Harvey Jul 16 '19 at 15:14
  • 2
    You and several of the commenters are focusing too much on syntax and parsers. Syntax is the least interesting part of a programming language and parsing is mostly a solved problem. The interesting thing about a programming language is its semantics, and that aspect hasn't even been mentioned once, let alone being specified in the question. What are the semantics of your homegrown language. What are the semantics of the language you are looking to replace it? Also, how is your homegrown language implemented? Is it a compiler? If yes, wouldn't it make more sense to build a compiler from the … – Jörg W Mittag Jul 17 '19 at 5:49
  • 2
    And now that you've stipulated to byte code output, maybe you can sell a standard programming language. – Robert Harvey Jul 17 '19 at 18:36
0

You probably don't want to use something like LLVM for your use case. It is an extremely flexible IR, which means you will end up having to implement a bunch of stuff you don't really need, just to get it to work. If you had to be able to run any arbitrary existing C program on your assembly language, then it would be worth it.

Parsers aren't really that hard to write. Mostly you have to get past all the computer science jargon. Do a search for recursive descent parsers for the easiest method to understand (in my opinion). The next easiest method is probably to find a parser combinator library for your language. After that, using a parser generator like bison.

The tricky part is taking the Abstract Syntax Tree your parser produces and outputting your target code. Parser tutorials usually have you make an interpreter because it's easier. Once you've gone through those, then made an interpreter for your custom language, you will have the background knowledge to have a better idea of what the next step is.

|improve this answer|||||
  • 2
    This isn't as easy as you think it is. The part of the C language specification that is just the syntax is about 150 pages long, and whatever the OP comes up with has to be robust enough to hold up to a company's use. – Robert Harvey Jul 16 '19 at 18:36
  • 1
    @RobertHarvey This answer is spot on. OP is not looking for literally C, just a C-like language. While not trivial, that is really simple. Most of C's syntactic complexity is just that silly syntax for types, which can be avoided entirely. The really difficult part of writing a transpiler isn't the parser, but testing edge cases and generating useful error messages. – amon Jul 16 '19 at 19:31
  • 3
    @amon: [shrug.] Let's take a home-grown assembly-like scripting language that already has known problems and add a new home-grown, non-standard language on top of it. Doesn't sound like a recipe for success to me. I like the hubris, but ... yikes. – Robert Harvey Jul 16 '19 at 19:56
  • @RobertHarvey sounds reasonable, that building a home-grown crappy custom-made layer on another homegrown more crappier layer leads to just having 2 piles of shit instead of one, but my idea is that the second (new) layer will have unified, standardized syntax, but does not have any extra on processing logics. That's entirely left on the legacy layer. So actually this modification can divide the language into two logical parts. Please tell me if my reasoning is wrong somewhere. – original.roland Jul 17 '19 at 7:22
  • Some food for thought: joelonsoftware.com/2006/09/01/wasabi and flak.tedunangst.com/post/… – Robert Harvey Jul 17 '19 at 15:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.