flat assembler
Message board for the users of flat assembler.

Index > Main > sorting the mathematical operations like this 2+10-2*4/3

Goto page Previous  1, 2
Author
Thread Post new topic Reply to topic
uart777



Joined: 17 Jan 2012
Posts: 369
uart777
Quote:
Still pondering a simple way to add support for parenthesis (to collapse common sub-expressions manually)
It may help to convert infix expressions to RPN (Reverse Polish Notation) first to remove parenthesis/precedence then interpret subexpressions (lvalue+rvalue) from left-to-right order using irps or forward+match.

My EXPRESSION.INC demonstrates the mechanics of a simple recursive descent parser. I couldn't think of a way to do this with macros.

References:

* Famous "red dragon compiler book": http://www.amazon.com/Compilers-Principles-Techniques-Alfred-Aho/dp/0201100886
* Recursive descent parser: http://en.wikipedia.org/wiki/Recursive_descent_parser
* Shunting yard algorithm: http://en.wikipedia.org/wiki/Shunting-yard_algorithm
Post 13 Jul 2013, 00:21
View user's profile Send private message Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 3035
Location: vpcmipstrm
bitRAKE
Thanks for the resources. I am a little familiar with parsing methods, but am working within the constraints of FASM's preprocessor. There is a workaround to avoid use of parentheses. Instead multiple equations could be processed and combined using the current macro implementation.

Instead let us look at the problem:

( A ) B

A => C + ( D
B => + E ) + F

( C + ( D ) + E ) + F

It seems three cases need to be parsed: the initial pair, and then possible unmatched ends. If results are stored on a separate stack we'd just need to push/pop from that stack to the other one. This works well with the previous optimization which reduced instruction count.

*This only works if all values are static because calculations are not really preformed in precedence order. No ++/-- or assignment bullshit.

_________________
¯\(°_o)/¯ unlicense.org
Post 14 Jul 2013, 01:27
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc
bitRAKE
I think, you're trying to parse it in a wrong way. The TS has already asked me the same question over PM in March. What I suggested was to use this macro as a starting point, but instead of displaying the expression to store the expression into a virtual section and to parse it using the load directive. This would be a much simpler way of parsing.

I also provided the following macro (for a little different purpose):
Code:
;Displays all tokens of an expression, delimiting them 
;with a specified string 
;usage: dispExp ' ', y = 17, x = 2*y+(y mod 12) shl 7 
macro dispExp delim*,[exp] 
{ 
        common match \exp,exp 
        \{ 
                _rest equ \exp 
                irps sym,\exp 
                \\{ 
                        display \\`sym 
                        match head tail, _rest 
                        \\\{ 
                                restore _rest 
                                _rest equ tail 
                                display delim 
                        \\\} 
                \\} 
                restore _rest 
        \} 
}    

See any similarity to the first post? Smile

_________________
Faith is a superposition of knowledge and fallacy
Post 14 Jul 2013, 11:41
View user's profile Send private message Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 3035
Location: vpcmipstrm
bitRAKE
Using the assembler directives would be a much easier approach.
Post 14 Jul 2013, 12:24
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc
bitRAKE
Yes. That's what I said.

_________________
Faith is a superposition of knowledge and fallacy
Post 14 Jul 2013, 12:25
View user's profile Send private message Reply with quote
tthsqe



Joined: 20 May 2009
Posts: 730
tthsqe
So is this post trying to evaluate expressions involving mathematical operators (no asignments or flow controls, ect.) purely through fasm's macros? You need a few stacks, which fasm has, but more importantly, you need to be able actually do the arithmetic operations, which fasm doesn't have for floating point. How is this being accomplished?
Post 14 Jul 2013, 14:07
View user's profile Send private message Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 3035
Location: vpcmipstrm
bitRAKE
I was under the impression Roman is trying to create a some sort of code generator, or rather I assumed that when he switched to using SSE instructions. Before that the goal was too vague, imho. Since others have already written parsers using assembler directives, thought I'd push the preprocessor method.
Post 15 Jul 2013, 00:26
View user's profile Send private message Visit poster's website Reply with quote
uart777



Joined: 17 Jan 2012
Posts: 369
uart777
Quote:
... parse it using the load directive. This would be a much simpler...
Here's a load/store example for those who don't know how to use them: Scroll through each character of literal text and convert to uppercase. Text may be a stream of tokens, names, operators and/or store in a list of equates...
Code:
text: db \          ; example text
 'abcdef', 0

i=0                 ; initialize
c=1                 ; counters

while c<>0          ; while not 0
 load c byte \      ; get c
  from text+i           
 if c>='a' & c<='z' ; lowercase?
  c=c-32            ; convert
 end if
 store byte c \     ; store result
  at text+i
 i=i+1              ; next c
end while    
Quote:
... calculations are not really preformed in precedence order. No ++/-- or assignment bullshit.
An alternative to infix expressions is to write multiple operations+statements on the same line separated with commas - . if a=b, n=f(1,2,3), end, p=a[i] - as in the following examples.

New ML in development: Future Macro Language. Ultimate ML that replaces C/C++/C#/Java. Easiest, most compact, highest production speed, direct memory access (for LL/systems programmers), C-style &address/*value, 100% FASM (not a backend or separate program), type safety and portability (X86+ARM).
Code:
; Future Macro Language...

! rgb(byte r, g, b) - color  
 . r1=r, r2=g, r1<<16, r2<<8, r1|r2, r1|b, end!  

! strlen(string s)  
 . r1=s, while *s, s++, endw, s-r1, s--, end! s  

! strcpy(string a, b)  
 . while *b, *a++=*b++, endw, *a=0, end! a  

! strcat(string a, b)  
 . strlen(a), r1+a, strcpy(r1, b), end! 

! strcmp(string a, b)  
 . while *a=*b and *a|*b, a++, b++, endw,\  
 r1=*a, r1-*b, end!  

! strchr(string s, char c)  
 . while *s, ? *s=c : return s, s++, endw, end! 0  

macro strequ a, b { . strcmp(a, b), ~r1 }  

! memcpyb(void *a, *b, u32 n)  
 . repeat n, (u8) *a++=*b++, endr, end!  

! memsetb(void *p, byte v, u32 n)  
 . repeat n, (u8) *p++=v, endr, end! 

; optional function/endf keywords 
; (for IDEs with syntax coloring). 
; all statements may be written on 
; individual lines... 

function rgb(byte r, g, b) - color  
 . r1=r, r2=g, r1<<16, r2<<8, r1|r2, r1|b 
endf 

function strlen(string s)  
 . r1=s 
 . while *s, s++, endw 
 . s-r1, s-- 
endf s 

function strcpy(string a, b)  
 . while *b, *a++=*b++, endw 
 . *a=0 
endf a 

function strcmp(string a, b)  
 . while *a=*b and *a|*b 
  . a++, b++ 
 . endw 
 . r1=*a, r1-*b 
endf    
Post 15 Jul 2013, 04:58
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.