An example expression parser.

EXP^ASM converts a standard "Infix" expression to "Reverse Polish Notation" (RPN) then to ASM with machine code. Dis/assembles code as you type.

Expression.INC uses a single-pass algorithm that produces 3+ times more effecient code than the popular "Let's Build a Compiler" tutorials by Jack Crenshaw (good introduction for beginners). ASM code must be rescanned and optimized (which is another subject that would take an entire book to explain considering the infinite number of ways that code can be written).

No time for questions. ASM experience is assumed. Designed in 1024x600/768 resolution. Includes 2 examples that are not graphical.



Download: http://sungod777.zxq.net/expression.zip

uart777,

How about common subexpressions and such?

baldr: Most optimizations can be performed while in RPN format - example: resolve constant subexpressions, re-order cumulative operations, etc - before conversion to ASM. In any case, this provides an interface for creating/testing expression algorithms.

uart777,

Constant expressions aren't good to show power of parser (they're constant and should be replaced with equivalent constants during compilation, right?).

Show me parser that will replace 1+2+3+...+n with n(n+1)/2 (when n is a run-time value), and I'll eat my hat.

Gauss was able to do that in his teen ages (as anecdote says).

I like the whole idea but also agree with baldr that your expression parser would be far more usable if you would allow use of symbolic constants inside the input field.

I've noticed an issue when I tried to enter some number of leading zeros before the digit. There is something that should be fixed, IMO (remove the unneeded leading zeros should be enough), see the attached screenshot:

Another thing: seems that your expression parser doesn't allow to use of negative numbers? See the screenshot:

Even use of parentheses doesn't help here:

it's cool how it is imo

[ Post removed by author. ]

HaHaAnonymous,

There is no specification, use the source, Luke.

It's incorrect in common sense, yet it may be some obscure way to signify "too exact one".

[ Post removed by author. ]

HaHaAnonymous,

OK, I'll explain. There is no specification this program adheres to, so the only chance to understand its behavior is to read program's source (in fact, it is even if specification exists). Though due to its highly macroed nature it's easier to use debugger.

1 to -119 translation is weird (and somewhat unstable), "too exact one" was intened pun, like 1.(0)

KevinN: Thanks. Your inquiries about compiler creation are what motivated me to upload this. Writing an expression is, by far, the greatest challenge in creating a HL compiler and I don't think most programmers here realize this.

Sorry, no time to explain.

[ Post removed by author. ]

Do you practice mind reading? Stop that, "it's bad for ya" © George Carlin. This ought to be clarified. Do you mean parsed? And, indeed, everything is replaced with runtime instructions (or else we get 42 every time). HL compilers can (and SHOULD) assume that registers are safe from [m] accesses (though I remember PDP-11 memory-maps them, near memory top). As to function calls, it's all the matter of calling conventions. Or, moreso, specifications. Function's specs should clearly identify what it requires/alters/results in.

Please, tell me why pointer to system clock should be considered as volatile? SMP, or maybe the value it's pointing to? Well, get back to your demanding projects. Your efforts are awesome, though language is quite arrogant.

P.S. !#name.$type='c' in LANGUAGE.INC::function macro should be !#name#.$type='c', probably.

if the code contains no branches this is a rather straightforward procedure
I am trying to implement general partial redundancy eliminations on jumpy code (for my calculator) and it is messy...

[ Post removed by author. ]

It IS otherwise!..

Reading and learning another persons macros takes a lot of time and effort. I also find it easier to read the actual assembly since I already know and understand that without having to refer to other things. I don't feel it is good use of my time to decode a set of complex macros for a one time task.

[rant]Just like with custom UI layout and format. So much time wasted trying to find the right button. Why do music player programmers (and now Windows 8) all seem to feel the need to build completely unfamiliar skins? All I need is basic menus and buttons. I don't need them all fancy colours, or weird shapes and sizes, in crazy positions, and other what-not.[/rant]

[ Post removed by author. ]