[libre-riscv-dev] Introduction

[Aleksandar Kostovic]

>
>  oh, can i suggest looking at the berkeley softfloat library, it seems
> to be a very clear implementation.  a copy is in the riscv-isa-tests,
> see e.g. softfloat/s_addMagsF32.c

WIll check it out.

Notes for dev...


Got it. I think i can manage with the rules. Will make sure i apply all of
git commit rules.

Now will examine berkely soft float

On Sun, Feb 3, 2019 at 8:25 AM Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> On Sunday, February 3, 2019, Jacob Lifshay <programmerjake at gmail.com>
> wrote:
>
> > I could write the calculator, shouldn't take very long. It will use
> > integers for i/o, they will be bitcasted to the fp types. This way we
> avoid
> > problems with decimal representations while still being simple enough to
> > implement since not everything can read/write hex floats (like
> > 0x1234.5678P+25).
>
>
> Yeh definitely int representation, fscanf does the job.
>
>
> >
> > Should I use infix notation, lisp-like S expressions, or RPN?
> > I think we should not use infix notation as it's harder to parse and not
> as
> > clear which order operators are being applied.
> >
> > RPN is the easiest to parse.
> > S expressions maintain the familiar operation nesting and is second
> easiest
> > to parse.
>
>
> I hadn't thought about it, basically needs to be dead simple, yet enough to
> represent FMULADD.
>
> even avoid stack, put operator first then operands, because operator can be
> done as a switch statement then straight to read of num of ops, then print
> result. Loop.
>
> fscanf to read line up to \n to get operator.
> switch statement
> fscanf with %x's to read operands.
>
>
>
>
>
> --
> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev
>