[Oberon] Risc-5 Instructions statistics

Jörg joerg.straube at iaeth.ch
Tue Feb 19 14:20:46 CET 2019


Walter

I can understand your point of view. You are adding and comparing costs of different HW elements.
You are creating new HW and obviously are wondering: "what elements should I use to make my HW design as cost effective as possible"
And yes, it's reasonable to say (form your point of view): why take an expensive FPGA to build a CPU, when there exists a cheap ARM CPU.
Now: why are you creating new HW in the first place? Most probably because you are not happy with the existing mainstream HW out there.

So, the same might happen to SW developers as well: they might want to build something new, as they are not happy with the existing mainstream SW.
With mainstream I mean C programing language, gcc and Linux.
Perhaps you are "just" user of gcc and Linux and never asked yourself what it needs to have gcc generating code for your CPU.

If you want to explore and research new SW paradigms, it all starts with the programming language, the compiler for it and later the operating system.
Writing a compiler for a CPU is doable but not an easy task. If the SW developer starts comparing costs, he wants to reuse his code as much as possible as this approach is the cheapest for him. Now instead of adapting a compiler to a mainstream CPU, it might be cheaper (for him) to invent a "new CPU" that fits to his compiler.

With FPGA it is reasonably easily possible to build an own CPU. For sure it's less expensive than to build a new ASIC just for you ( When you introduce a new SW element to your programing language (like eg interrupt handlers), you might need to adapt your programming language, your compiler and after all even need new CPU instructions. FPGA allows you to do exactly this. It's not the pure cost but the FPGA's flexibility that is important to the SW researcher.

br
Jörg

Am 19.02.19, 13:30 schrieb "Oberon im Auftrag von Walter Gallegos" <oberon-bounces at lists.inf.ethz.ch im Auftrag von waltergallegos at vera.com.uy>:

    Hi Wojtek,
    
    I try to post on Oberon list, no success after many days...
    
    Yes for me the focus is the special hardware not the micro-controller. 
    In FPGA arena this must be the focus, let me try to explain for what I 
    insist at point.
    
    Industry rules have well know constraints.
    
    To use a 28 USD chip I need justify that this chip provide the best 
    solution. A basic rule in industry is : a project use FPGA because is 
    the only practical solution if not use a micro-controller.
    
    In this context, chose a bigger component adding 6.44 USD (+23%) to the 
    costs when an ARM cost around 3.5 USD could be hard to justify. Beside 
    the cost of a chip is the development cost that in case of ARM is 
    significantly lower because it is a better know component than an FPGA.
    
    Combined this cost with Paul numbers I could conclude that in the case 
    of DSP blocks for multiplication adding 23% to the cost of each unit 
    optimize only 0.16% of the software. A questionable conclusion, I agree, 
    but illustrate the type of analysis that we need do.
    
    Can be argument that for cases where multiplication is lot much used the 
    software be optimized lot more, but the bottle neck, again based in Paul 
    number, are load and store operations. If a project have lot of math 
    build a dedicated processor ( a fixed state machine ) in hardware. I use 
    this approach all times for DSP as image processing, filtering, 
    convolutions, interpolation, etc.
    
    This is the mind switch that many software designers need be to do for 
    work with FPGA. If not they are using a costly all terrain truck as a 
    compact car.
    
    I insist because I would like to see a growing community but for that it 
    has to fit into the industry and play by it rules.
    
    Feel free to post this in Oberon list.
    Regards,
    
    Walter
    
    
    --
    Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
    https://lists.inf.ethz.ch/mailman/listinfo/oberon
    




More information about the Oberon mailing list