Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #33927

Re: Clarity vs. Efficiency

Show all headers | View raw

forthisit@gmail.com wrote:

> I recently wrote some code (for an embedded Forth processor) to convert a
> user's desired frequency into control register values to be written to
> Xilinx's PLL (which they call MMCM, for mixed mode clock manager). In this
> way the frequency output can be changed dynamically to any desired value
> (within certain resolution limits, of course) without changing the FPGA's
> hardware design. It was a fun project.
> 
> Here are two of the words developed along the way:
> 
> \ calculate "M"
> : fbdiv  ( -- n ) \ aka M (multiplier)
>     drp_freq $1FF and    \ strip off [12:9]
>     2 rshift
>     >606? IF 2/
>     ELSE >400? not IF 2/ THEN
>     THEN ;
> 
> \ calculate value for CLKFBOUT's CLKREG1 register
> : fbreg1  ( -- n )
>     fbdiv 2/           ( n )
>     frac? IF 1 - THEN  ( n )  \ fractional divide adds undocumented '2'
>     dup                ( n n )\ (ie. 1 in frac bits gives M of 2.125,not
>     0.125)
>     fbdiv odd? +       ( h l )\ if M is odd LOW_TIME = HIGH_TIME + 1
>     swap 6 lshift or   ( n )
> ;
> 
> I don't want to belabor the point with too many hardware details, but
> suffice it to say that the PLL uses many dividers/counters. If you place a
> divider in a PLL feedback path it actually functions as a multiplier. The
> value for this parameter is labeled "M" in Xilinx's block diagrams of the
> MMCM. For the few (maybe none) who care, here are all the gruesome details
> Xilinx gives for exercising the MMCM DRP (dynamic reconfiguration port):
> 
http://www.xilinx.com/support/documentation/application_notes/xapp888_7Series_Dy
> namicRecon.pdf
> 
> So fbdiv basically retrieves the desired frequency setting, returned by
> drp_freq, and calculates and returns "M". The value of "M" is required in
> the calculation of more than one control register value. From an
> efficiency perspective it would be best to only calculate this once, store
> it in a variable or on the stack, and retrieve it as needed. But from a
> clarity perspective I found that I liked the expressiveness of just
> calling the fbdiv word whenever I needed the value of "M" in the
> calculations (as in the fbreg1 word above). It saves variable space,
> reduces the so called "stack juggling" that Forth is often criticized for,
> and it really helped when checking my words interactively using Gforth as
> I coded.
> 
> It got me to thinking that if more code was written like this, especially
> when making the case for the acceptance of Forth, the code might be more
> easily understood and better appreciated; even though it sacrifices some
> efficiency. I felt that this embedded Forth processor running Forth code
> is so fast already that I'm willing to sacrifice a little efficiency for
> clarity.
> 
> Agree or disagree?

I agree also and echo Andrew's constraint that the response time objectives 
of the system continue to be met.

However, there are other ways of making the intent of your code clear 
through adopting a literal style of code and comment layout. Think of the 
Glossary Entry (marked with a G: in a comment line) to be the statement of 
requirements for the functional behaviour of the word and setting out the 
expected limitations.

This will also help in efforts to fully certify the code you generate as, by 
inspection, functional test and limitations testing you can confirm that 
your code fully meets that statement of requirements. See my paper "High 
Integrity Systems C.O.D.E for more on this particular topic (on the 
EuroForth website when Anton gets to put this years proceedings up).

-- 
********************************************************************
Paul E. Bennett IEng MIET.....<email://Paul_E.Bennett@topmail.co.uk>
Forth based HIDECS Consultancy.............<http://www.hidecs.co.uk>
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Clarity vs. Efficiency forthisit@gmail.com - 2014-10-15 08:54 -0700
  Re: Clarity vs. Efficiency Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-15 11:32 -0500
  Re: Clarity vs. Efficiency Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2014-10-15 22:06 +0100
  Clarity vs. Efficiency november.nihal@gmail.com - 2014-10-15 15:19 -0700
    Re: Clarity vs. Efficiency forthisit@gmail.com - 2014-10-16 07:04 -0700
  Re: Clarity vs. Efficiency "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-10-17 21:48 -0400
  Re: Clarity vs. Efficiency gavino_himself <visploveslisp@gmail.com> - 2014-10-20 22:06 -0700

csiph-web