flat assembler
Message board for the users of flat assembler.

 Index > Tutorials and Examples > EXP^ASM - Expression Parser, Dis/Assembler Goto page 1, 2  Next
Author
uart777

Joined: 17 Jan 2012
Posts: 369
uart777 28 Mar 2013, 14:53
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.

Last edited by uart777 on 27 Aug 2013, 03:19; edited 1 time in total
28 Mar 2013, 14:53
baldr

Joined: 19 Mar 2008
Posts: 1651
baldr 28 Mar 2013, 15:08
uart777,

How about common subexpressions and such?
28 Mar 2013, 15:08
uart777

Joined: 17 Jan 2012
Posts: 369
uart777 28 Mar 2013, 15:15
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.
28 Mar 2013, 15:15
baldr

Joined: 19 Mar 2008
Posts: 1651
baldr 28 Mar 2013, 15:38
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).
28 Mar 2013, 15:38
MHajduk

Joined: 30 Mar 2006
Posts: 6115
Location: Poland
MHajduk 28 Mar 2013, 15:56
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:

28 Mar 2013, 15:56
MHajduk

Joined: 30 Mar 2006
Posts: 6115
Location: Poland
MHajduk 28 Mar 2013, 16:03
Another thing: seems that your expression parser doesn't allow to use of negative numbers? See the screenshot:

28 Mar 2013, 16:03
MHajduk

Joined: 30 Mar 2006
Posts: 6115
Location: Poland
MHajduk 28 Mar 2013, 16:09
Even use of parentheses doesn't help here:

28 Mar 2013, 16:09
KevinN

Joined: 09 Oct 2012
Posts: 160
KevinN 28 Mar 2013, 16:52
it's cool how it is imo
28 Mar 2013, 16:52
HaHaAnonymous

Joined: 02 Dec 2012
Posts: 1178
Location: Unknown
HaHaAnonymous 28 Mar 2013, 17:32
[ Post removed by author. ]

Last edited by HaHaAnonymous on 28 Feb 2015, 21:14; edited 1 time in total
28 Mar 2013, 17:32
baldr

Joined: 19 Mar 2008
Posts: 1651
baldr 28 Mar 2013, 20:13
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".
28 Mar 2013, 20:13
HaHaAnonymous

Joined: 02 Dec 2012
Posts: 1178
Location: Unknown
HaHaAnonymous 28 Mar 2013, 21:27
[ Post removed by author. ]

Last edited by HaHaAnonymous on 28 Feb 2015, 21:14; edited 1 time in total
28 Mar 2013, 21:27
baldr

Joined: 19 Mar 2008
Posts: 1651
baldr 29 Mar 2013, 06:52
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)
29 Mar 2013, 06:52
uart777

Joined: 17 Jan 2012
Posts: 369
uart777 29 Mar 2013, 07:41
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.

Last edited by uart777 on 07 Aug 2013, 19:14; edited 2 times in total
29 Mar 2013, 07:41
uart777

Joined: 17 Jan 2012
Posts: 369
uart777 29 Mar 2013, 07:55
[ Post removed by author. ]

Last edited by uart777 on 07 Aug 2013, 19:18; edited 1 time in total
29 Mar 2013, 07:55
baldr

Joined: 19 Mar 2008
Posts: 1651
baldr 29 Mar 2013, 09:06
uart777 wrote:
Wrong Your statement indicates that you know nothing about expression parsers and have never written one in your lifetime, not the simplest one in the highest level language.
I'm too old to know everything.
uart777 wrote:
Any expression parser - whether it produces a constant or variable result - can be replaced with [m] and runtime instructions.
This ought to be clarified. Do you mean parsed? And, indeed, everything is replaced with runtime instructions (or else we get 42 every time).
uart777 wrote:
In addition, please note that with [m] operands, HL compilers generally assume that function calls alter all registers and volatile variables (example, a pointer to system clock) can change from one instruction to the next.
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?
uart777 wrote:
Sorry, no time to explain.
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.
29 Mar 2013, 09:06
tthsqe

Joined: 20 May 2009
Posts: 767
tthsqe 29 Mar 2013, 10:04
Quote:
How about common subexpressions and such?

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...
29 Mar 2013, 10:04
HaHaAnonymous

Joined: 02 Dec 2012
Posts: 1178
Location: Unknown
HaHaAnonymous 29 Mar 2013, 13:33
[ Post removed by author. ]

Last edited by HaHaAnonymous on 28 Feb 2015, 21:14; edited 1 time in total
29 Mar 2013, 13:33
AsmGuru62

Joined: 28 Jan 2004
Posts: 1590
AsmGuru62 29 Mar 2013, 14:04
It IS otherwise!..
29 Mar 2013, 14:04
revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20207
revolution 29 Mar 2013, 14:31
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]
29 Mar 2013, 14:31
HaHaAnonymous

Joined: 02 Dec 2012
Posts: 1178
Location: Unknown
HaHaAnonymous 29 Mar 2013, 15:33
[ Post removed by author. ]

Last edited by HaHaAnonymous on 28 Feb 2015, 21:09; edited 1 time in total
29 Mar 2013, 15:33
 Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First

 Jump to: Select a forum Official----------------AssemblyPeripheria General----------------MainTutorials and ExamplesDOSWindowsLinuxUnixMenuetOS Specific----------------MacroinstructionsOS ConstructionIDE DevelopmentProjects and IdeasNon-x86 architecturesHigh Level LanguagesProgramming Language DesignCompiler Internals Other----------------FeedbackHeapTest Area
Goto page 1, 2  Next

Forum Rules:
 You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum