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

Groups > comp.lang.forth > #33918 > unrolled thread

Clarity vs. Efficiency

Back to article view | Back to comp.lang.forth

Contents

  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

#33918 — Clarity vs. Efficiency

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?

[toc] | [next] | [standalone]

#33922

forthisit@gmail.com wrote:

> 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?

Agree, strongly.  As long as you hit the real-time deadline every
time, keep it simple.

Andrew.

[toc] | [prev] | [next] | [standalone]

#33927

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..
********************************************************************

[toc] | [prev] | [next] | [standalone]

#33929

I wondered what you meant when you used the phrase : when making the case for the acceptance of forth. Who is making the case and to whom ? 

[toc] | [prev] | [next] | [standalone]

#33942

On Wednesday, October 15, 2014 5:19:27 PM UTC-5, novembe...@gmail.com wrote:
> I wondered what you meant when you used the phrase : when making the case for the acceptance of forth. Who is making the case and to whom ?

I just meant in the general sense of arguing for, or desiring, more wide-spread use of Forth.

[toc] | [prev] | [next] | [standalone]

#33993

On Wed, 15 Oct 2014 11:54:53 -0400, <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 )
> ;
>

Should you have posted these publicly?  (Just a thought. No reply needed.)

> [...]
>
> 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?
>

By "like this," do you mean both 1) not using the stack, and
2) not using variables?  That kind of neuters Forth doesn't it?

I can see avoiding "stack juggling," but just how much variable
space do you save by _not_ retrieving a variable?  2 bytes? 4 bytes?

Of course, fbdiv could just retrieve that variable, not compute it.
I.e., shouldn't your code should probably be written that way already?


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#34045

On Wednesday, October 15, 2014 8:54:54 AM UTC-7, fort...@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?

vote republican

workout hard

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.forth

csiph-web