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


Groups > comp.lang.forth > #38049

Re: Rockwell R65F11

Date 2015-04-07 20:18 +0100
From Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>>
Newsgroups comp.lang.forth
Subject Re: Rockwell R65F11
Message-ID <20150407201813.71891756@T60A> (permalink)
References (4 earlier) <551d2736$0$3060$e4fe514c@dreader35.news.xs4all.nl> <20150403121645.6705fc14@T60A> <87vbhd6v02.fsf@jester.gateway.sonic.net> <20150406105114.38629028@T60A> <87zj6l9duc.fsf@jester.gateway.sonic.net>

Show all headers | View raw


On Mon, 06 Apr 2015 13:55:07 -0700
Paul Rubin <no.email@nospam.invalid> wrote:

> Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> writes:
> > If there was an ideal engine, it could start work in small embedded 
> > systems with no libraries, then, as it grew then libraries would be 
> > translated or written.
> 
> Lists, dictionaries, strings, and a few other types are very fundamental
> to Python so you'd need them, though I guess they are doable. 

Only met Lists and Dictionaries recently when starting to use Python for 
hardware design, so could probably do simple embedded without them.
 
> The bytecode stuff isn't inherent to Python at all, it's just a detail
> of how one particular implementation works.  That happens to be the most
> widely used implementation (CPython), but the most advanced
> implementation (PyPy) has a JIT compiler. 

Yes, PyPy is magnificent.  It can brings the performance of the MyHDL 
simulator up to the same speed as tools written in other languages. [1] 

> You might also look at Lua (uses a register-based VM), Picobit (uses
> bytecode), and Microscheme (generates AVR 8-bit native code but
> currently has no garbage collector).

I'd heard of Lua, but not looked at the VMs before, thanks.  Picobit 
was most interesting, with it's inherent support for bignums.  I'm 
not sure how to handle arrays or stack frames containing bignums. 

Can algorithms which operate on arrays be re-arranged to operate on 
streams of data (bignums). This adds compression, compared with using 
an very large array, especially if much of the data is close to zero. 
This then could reduce required memory bandwidth. 

For example, might an FFT re-order data on each pass ready for the next 
pass by stream division?  

Jan Coombs. 
-- 
email valid, else fix dots and hyphen
jan4clf2014@murrayhyphenmicroftdotcodotuk

[1] http://old.myhdl.org/doku.php/performance

Lua VM "Stack-machine instructions are too low level"
http://www.inf.puc-rio.br/~roberto/talks/lua-ll3.pdf

Picobit VM - bignums stored in heap
http://www.ccs.neu.edu/home/stamourv/papers/picobit.pdf




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


Thread

Rockwell R65F11 Derek Simmons <dereks314@gmail.com> - 2015-03-23 15:52 -0700
  Re: Rockwell R65F11 "WJ" <w_a_x_man@yahoo.com> - 2015-03-23 23:46 +0000
    Re: Rockwell R65F11 Jason Damisch <jasondamisch@yahoo.com> - 2015-03-23 17:24 -0700
  Re: Rockwell R65F11 Derek Simmons <dereks314@gmail.com> - 2015-03-23 17:33 -0700
    Re: Rockwell R65F11 visualforth@rocketmail.com - 2015-03-24 21:44 -0700
      Re: Rockwell R65F11 hughaguilar96@gmail.com - 2015-03-25 14:47 -0700
        Re: Rockwell R65F11 rickman <gnuarm@gmail.com> - 2015-03-25 18:42 -0400
      Re: Rockwell R65F11 Derek Simmons <dereks314@gmail.com> - 2015-03-25 19:43 -0700
      Re: Rockwell R65F11 Derek Simmons <dereks314@gmail.com> - 2015-03-25 20:08 -0700
        Re: Rockwell R65F11 visualforth@rocketmail.com - 2015-03-25 21:41 -0700
          Re: Rockwell R65F11 hughaguilar96@gmail.com - 2015-03-25 22:43 -0700
            Re: Rockwell R65F11 Derek Simmons <dereks314@gmail.com> - 2015-03-26 11:42 -0700
              Re: Rockwell R65F11 "WJ" <w_a_x_man@yahoo.com> - 2015-03-26 20:50 +0000
                Re: Rockwell R65F11 visualforth@rocketmail.com - 2015-03-26 18:07 -0700
            Re: Rockwell R65F11 visualforth@rocketmail.com - 2015-03-26 13:11 -0700
              Re: Rockwell R65F11 hughaguilar96@gmail.com - 2015-03-26 21:11 -0700
                Re: Rockwell R65F11 visualforth@rocketmail.com - 2015-03-26 22:14 -0700
                Re: Rockwell R65F11 hughaguilar96@gmail.com - 2015-03-28 16:57 -0700
            Re: Rockwell R65F11 hughaguilar96@gmail.com - 2015-03-28 17:18 -0700
              Re: Rockwell R65F11 Derek Simmons <dereks314@gmail.com> - 2015-03-31 11:05 -0700
                Re: Rockwell R65F11 Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-04-02 10:20 +0100
                Re: Rockwell R65F11 albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-02 11:25 +0000
                Re: Rockwell R65F11 Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-04-03 12:16 +0100
                Re: Rockwell R65F11 Paul Rubin <no.email@nospam.invalid> - 2015-04-03 09:23 -0700
                Re: Rockwell R65F11 Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-04-06 10:51 +0100
                Re: Rockwell R65F11 Paul Rubin <no.email@nospam.invalid> - 2015-04-06 13:55 -0700
                Re: Rockwell R65F11 Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-04-07 20:18 +0100
                Re: Rockwell R65F11 Paul Rubin <no.email@nospam.invalid> - 2015-04-07 19:02 -0700
                Re: Rockwell R65F11 Paul Rubin <no.email@nospam.invalid> - 2015-04-02 16:10 -0700
                Re: Rockwell R65F11 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-04-02 22:57 -0700
                Re: Rockwell R65F11 Paul Rubin <no.email@nospam.invalid> - 2015-04-03 00:06 -0700
                Re: Rockwell R65F11 hughaguilar96@gmail.com - 2015-04-03 09:00 -0700
  Re: Rockwell R65F11 Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-04-08 08:27 +0100
    Re: Rockwell R65F11 Derek Simmons <dereks314@gmail.com> - 2015-04-24 12:22 -0700
      Re: Rockwell R65F11 hughaguilar96@gmail.com - 2015-04-24 13:38 -0700
        Re: Rockwell R65F11 Derek Simmons <dereks314@gmail.com> - 2015-04-25 08:35 -0700

csiph-web