Parse Floating Point Constants #2195
Conversation
jiahanxie353
force-pushed
the
frontend-parse-fp
branch
from
1c8e8c8
to
ce90f1d
Compare
| }, | ||
| "mem_write": { | ||
| "data": [ | ||
| 4.2 |
There was a problem hiding this comment.
Oh the second thought is that it only proves that it reads/writes the same value, but doesn't prove that it's not necessarily intepretting 4.2 as the decimal representation..
There was a problem hiding this comment.
Can you explain what you mean by that? The comment is lacking enough context to make sense to me.
calyx-frontend/src/syntax.pest
Outdated
| @@ -26,7 +27,8 @@ num_lit = ${ | |||
| ~ ( "d" ~ decimal | |||
| | "b" ~ binary | |||
| | "x" ~ hex | |||
| | "o" ~ octal ) | |||
| | "o" ~ octal | |||
| | "f" ~ float) | |||
There was a problem hiding this comment.
One challenging thing about this is that we are hardcoding IEEE-754 encoding for floating point and might eventually want to support things like posits (something that @Mark1626 was working on) so we might want a different way to specify floating point numbers?
@sampsyo thoughts? One thing I was thinking is that the syntax is only available in a magical primitive:
cf1 = ieee754_const(5.11231); // Error if exact representation is not possibleThere was a problem hiding this comment.
@jiahanxie353 What do you think about this approach? Instead of allowing floating point constants, we define a primitive ieee754_const and only allow the parser to parse floating point values within as its parameters. In all other cases, we throw an error saying that floating point constants must be generated using this special cell.
This will require some trickery in the parser/well-formedness checker but hopefully not too complicated?
There was a problem hiding this comment.
@jiahanxie353 ping about this!
jiahanxie353
force-pushed
the
frontend-parse-fp
branch
from
ce90f1d
to
269ec2c
Compare
|
Currently, it keeps saying: Error: tests/correctness/float/float-const.futil
13 | reg0.in = ieee754_const(32'f1.0);
| ^ Parse error
expected guard_eq, guard_neq, guard_leq, guard_geq, guard_lt, guard_gt, guard_or, or guard_andAny advice on how to fix the parsing? |
|
I'm not sure what is happening with the PR: the diff is too big for me to read the changes you've added. |
… decimal representation of real numbers
jiahanxie353
force-pushed
the
frontend-parse-fp
branch
from
4dcea02
to
36cf6ba
Compare
Now it should cleaner! |
| wires { | ||
| group read { | ||
| mem_read.addr0 = 1'b0; | ||
| reg0.in = ieee754_const(1.00); |
There was a problem hiding this comment.
@sampsyo thoughts on this representation as opposed to the idea of only having a primitive called ieee754 and using its output port?
|
@jiahanxie353 your pattern for float is: So how would the following thing match it: |
| @@ -16,17 +16,22 @@ binary = @{ ASCII_HEX_DIGIT+ } | |||
| decimal = @{ ASCII_HEX_DIGIT+ } | |||
| octal = @{ ASCII_HEX_DIGIT+ } | |||
| hex = @{ ASCII_HEX_DIGIT+ } | |||
| float = @{ ASCII_DIGIT+ ~ "." ~ ASCII_DIGIT+ } | |||
|
|
|||
| ieee754_const = { "ieee754_const(" ~ float ~ ")" } | |||
There was a problem hiding this comment.
separate out iee754_const( into "ieee754" ~ "("
|
Another note from a synchronous chat: IEEE754 requires information on the number of bits being used. |
This PR tries to address #2061
Support: