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

Groups > comp.lang.forth > #33993

Re: Clarity vs. Efficiency

Show all headers | View raw

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

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