[Microbit-Python] memory error

David Whale david at thinkingbinaries.com
Sat Oct 3 18:26:04 CEST 2015 

oooo! Inline Assembler! Tell Howard about that - he remembers the inline
assembler on the original BBC Micro!

Actually, my 11 year old coding exploits were in *machine code* not
*assembler* - there was no assembler on the ZX81, I had to look the
instructions up in the index of the manual, construct the operands myself,
and poke each instruction in by hand and then jump to it! A good trick on
my 1K ZX81 was to use only the left half of the screen, because the screen
was dynamically sized, using less screen space meant more program space - I
wrote a machine code asteroids that worked on the left hand side of the
screen in only 1K.

Good work, Damien!

David


___________________________________________________________
David Whale, B.Sc (Hons), MIET
*Software Engineer and IET Schools Liaison Officer, Essex*

email:  dwhale at theiet.org
twitter: @whaleygeek
blog:  blog.whaleygeek.co.uk

Co-author of the new book "Adventures in Minecraft" <http://amzn.to/ZGfxZG>
- lets get kids coding!


On 3 October 2015 at 17:20, Damien George <damien.p.george at gmail.com> wrote:

> Yes, I think that at the moment 3kb is too limiting for maximum script
> size.  I honestly didn't think people would be writing such complex
> programs, but agree that it would be very annoying if your efforts
> coding all day lead only to out of memory errors.
>
> If we can cater for the more advanced coders and provide more memory
> for scripts, then we should.  And I have some ideas (inspired by
> David) of how to do it and might be able to get close to 10kb for
> maximum script.  I'll keep you posted!
>
> Regarding assembler: actually MicroPython does include an inline
> assembler!  But it's not enabled for the microbit.  I was thinking of
> enabling it but it does take a bit of room (around 6500 bytes of
> flash).  One cute option is to simply create a function that turns a
> byte string into a callable assembler function.  Eg:
>
> fun = microbit.assembler(num_args=3, code=b'\x12\x34\x56')
> fun(1, 2, 3)
>
> Then you can write your assembly function in hex (!!) and do arbitrary
> things with the device.
>
> Regarding David's point about resource contraints leading to learning.
> I totally agree!  Even if in the case of MicroPython you're not
> learning about stacks and pointers, you are learning that making a
> list takes memory, and higher level things like that.  Even writing
> Python on your PC you sometimes need to think about how resource
> intensive it is and how to make it more efficient (eg use a better
> algorithm).
>
>
> On Sat, Oct 3, 2015 at 7:41 AM, David Whale <david at thinkingbinaries.com>
> wrote:
> > :)
> >
> > My point was less about machine code, and more about "if resources are
> > limited, additional learning takes place". I  learnt a lot about how the
> > computer worked, by finding other ways to make my programs fit.
> >
> > I'm not suggesting every 11 year old would be interested in breaking
> beyond
> > the memory restrictions, some will, some won't. I think as long as we
> have a
> > view on "what a reasonable sized program is for most users", it will
> still
> > be a great experience.
> >
> > My follow on point was to not break our backs getting the last byte out
> of
> > the memory, but something that maps out the memory usage would encourage
> > those persistent souls who want to. That would be far less work than
> > squeezing the last few bytes out of the language design, and possibly a
> self
> > contained task that someone else could do to one side.
> >
> > Cheers
> >
> > David
> >
> >
> >
> >
> > ___________________________________________________________
> > David Whale, B.Sc (Hons), MIET
> > Software Engineer and IET Schools Liaison Officer, Essex
> >
> > email:  dwhale at theiet.org
> > twitter: @whaleygeek
> > blog:  blog.whaleygeek.co.uk
> >
> > Co-author of the new book "Adventures in Minecraft" - lets get kids
> coding!
> >
> >
> > On 3 October 2015 at 00:02, Alan <alainjackson at hotmail.com> wrote:
> >>
> >> Hi David,
> >>
> >> I find your argument about resource constraints compelling.
> >>
> >> I never did learn to program my 1K ZX81 in assembler. I blew it up
> before
> >> then.
> >>
> >> Remember how AWFUL the keyboard was? I soldered a joystick from an old
> >> space invaders game into the keyboard matrix so I could play games
> better...
> >> but when trying to add more buttons later I dropped the soldering iron
> on
> >> the CPU. Game over.
> >>
> >> I didn't see assembler until I was at uni... and the moment had passed.
> >> But ever since then I've been in awe of people who can do assembler.
> >>
> >> I would find your argument even more compelling if we were thinking of
> >> python as a gateway drug to assembler. If we had an assembler tool-chain
> >> shipping along with micropython.
> >>
> >> I think we, as a bunch of python people, seeing the device through a
> >> pythonic lens, for us there maybe an objectively optimal memory range,
> which
> >> I personally think is greater than 3KB.... for python.
> >>
> >> But if we're part of encouraging a descent into assembler, then I could
> be
> >> convinced that less is more.
> >>
> >> Cheers,
> >>
> >> Alan
> >>
> >>
> >> ________________________________
> >> Date: Fri, 2 Oct 2015 23:09:59 +0100
> >> From: david at thinkingbinaries.com
> >>
> >> To: microbit at python.org
> >> Subject: Re: [Microbit-Python] memory error
> >>
> >> I think it would be useful to have a rough metric or target of the sort
> of
> >> script/size that would be reasonably expected on a platform of this
> size. It
> >> might be that on the whole, all the things that people are writing will
> >> basically fit, if some basic good practice in naming and layout is
> followed.
> >>
> >> I also think back to the earlier discussion about limited memory on the
> >> ZX81, and the fact that I spent most of my working life up until now
> >> squeezing lots of functionality into tiny processors with limited
> resources,
> >> and the skills I learnt on my 1K ZX81 were vital to enabling that
> >> innovation. The door push on the front of my house has my code in it,
> it's a
> >> commercial product you can buy off the shelf, and it wouldn't have if I
> >> didn't cut my teeth on a resource limited platform which forced me to
> >> understand how the computer actually worked. I was 11 when I had my
> ZX81 and
> >> I was writing Z80 assembler as a way to make things fit. On the whole
> it was
> >> a really exciting experience for an 11 year old!
> >>
> >>
> >> One of the things to remember is that modern computers (even the
> Raspberry
> >> Pi) mostly allow you to assume infinite resources (or pretty
> unbounded). The
> >> micro:bit is very much an embedded platform, and having a limit on
> resources
> >> causes people to understand that nothing is infinite in this world, and
> >> that's a good thing sometimes!
> >>
> >> So, let's not beat ourselves up about it. As long as a good
> representative
> >> set of engaging and exciting programs can be made to fit, there has to
> be
> >> some limit. And besides - save some work for version 2!!!
> >>
> >> As an aside, if someone were to develop a toolkit that helped to explain
> >> where the memory usage in a given MicroPython program goes to, it would
> >> enable users to optimise their programs better themselves and gain a
> better
> >> understanding of how things work. I'm sure Damien is the same, when
> working
> >> on an embedded platform I spend my life in the map file and often in the
> >> assembly listings too, to understand where all the precious memory is
> going
> >> to!
> >>
> >> David
> >>
> >>
> >> ___________________________________________________________
> >> David Whale, B.Sc (Hons), MIET
> >> Software Engineer and IET Schools Liaison Officer, Essex
> >>
> >> email:  dwhale at theiet.org
> >> twitter: @whaleygeek
> >> blog:  blog.whaleygeek.co.uk
> >>
> >> Co-author of the new book "Adventures in Minecraft" - lets get kids
> >> coding!
> >>
> >>
> >> On 2 October 2015 at 22:46, Damien George <damien.p.george at gmail.com>
> >> wrote:
> >>
> >> Yes, variable name length will have a small impact on RAM usage.
> >>
> >> Yes, as David says, a given variable is only stored once in RAM and
> >> then referenced by an index (which is usually 16 bits) so it's
> >> relatively efficient.  You need to keep the actual name of the
> >> variable around so that you can given sensible error messages, and
> >> also for lookup of global names in dictionaries.
> >>
> >> There are definitely things that we can do to improve the memory usage
> >> and allow bigger scripts.  Do you think it's a priority?
> >>
> >> On Fri, Oct 2, 2015 at 6:17 PM, David Whale <david at thinkingbinaries.com
> >
> >> wrote:
> >> > I only had a 1K ZX81 and it forced me to learn machine code so I could
> >> > make
> >> > everything fit :)
> >> >
> >> > I'm *guessing* that MicroPython has a fixup table, so that the
> variable
> >> > names and function names are only stored in RAM once - i.e. each
> >> > reference
> >> > to a function name or variable name in the bytecode is actually an
> index
> >> > into a string table with the actual name in it? Perhaps a one-way hash
> >> > could
> >> > be used to turn any given name into a shorter hash that is actually
> used
> >> > for
> >> > the lookup?
> >> >
> >> > Cheers
> >> >
> >> > D
> >> >
> >> >
> >> > ___________________________________________________________
> >> > David Whale, B.Sc (Hons), MIET
> >> > Software Engineer and IET Schools Liaison Officer, Essex
> >> >
> >> > email:  dwhale at theiet.org
> >> > twitter: @whaleygeek
> >> > blog:  blog.whaleygeek.co.uk
> >> >
> >> > Co-author of the new book "Adventures in Minecraft" - lets get kids
> >> > coding!
> >> >
> >> >
> >> > On 2 October 2015 at 18:06, Alan <alainjackson at hotmail.com> wrote:
> >> >>
> >> >> Hi,
> >> >>
> >> >> Am I right in thinking the size of variable names also makes a
> >> >> difference?
> >> >> It seemed to, although I didn't test that scientifically.
> >> >>
> >> >> 3KB is a bit small. I know, however big the memory we'd always want
> >> >> more.
> >> >> And I did grow up programming a ZX81, so this is 3 times as big!
> You'd
> >> >> think
> >> >> I'd be happy with that.
> >> >>
> >> >> Cheers,
> >> >>
> >> >> Alan
> >> >>
> >> >> > Date: Fri, 2 Oct 2015 16:07:02 +0100
> >> >>
> >> >> > From: damien.p.george at gmail.com
> >> >> > To: microbit at python.org
> >> >> > Subject: Re: [Microbit-Python] memory error
> >> >> >
> >> >> > Hi Alan,
> >> >> >
> >> >> > Yes, doc strings do take up memory, so in our case (when trying to
> >> >> > reduce memory usage) it's better to make them comments (which are
> >> >> > just
> >> >> > skipped over by the tokeniser).
> >> >> >
> >> >> > The example you give with lots of prints does indeed take up all
> the
> >> >> > memory, so that's why it gives a MemoryError. It's not easy to fix
> >> >> > this, the microbit is just really low on RAM! We could compile the
> >> >> > python script to flash (instead of RAM) but that needs a bit of
> >> >> > effort
> >> >> > to get working.
> >> >> >
> >> >> > Cheers,
> >> >> > Damien.
> >> >> >
> >> >> >
> >> >> > On Thu, Oct 1, 2015 at 2:52 AM, Alan <alainjackson at hotmail.com>
> >> >> > wrote:
> >> >> > > Hi,
> >> >> > >
> >> >> > > Another little trick I've realised is that if I put a large,
> >> >> > > explanatory
> >> >> > > comment at the top of the file using """...""" it of course goes
> >> >> > > into
> >> >> > > a
> >> >> > > docstring... which takes up memory!
> >> >> > >
> >> >> > > If I use # style comments instead, it doesn't seem to take up
> >> >> > > memory.
> >> >> > >
> >> >> > > Cheers,
> >> >> > >
> >> >> > > Alan
> >> >> > >
> >> >> > > ________________________________
> >> >> > > From: alainjackson at hotmail.com
> >> >> > > To: microbit at python.org
> >> >> > > Date: Thu, 1 Oct 2015 00:32:14 +0000
> >> >> > >
> >> >> > > Subject: Re: [Microbit-Python] memory error
> >> >> > >
> >> >> > > Hi,
> >> >> > >
> >> >> > > I didn't save the version of my code that got the memory error.
> >> >> > >
> >> >> > > But I've just now created a small, pathological example.
> >> >> > >
> >> >> > > The code below, which is 3kB on the disk, will create the
> following
> >> >> > > error:
> >> >> > >
> >> >> > >>>> MemoryError:
> >> >> > > Micro Python v1.4.5-68-g3a2171e on 2015-09-04; micro:bit with
> >> >> > > nRF51822
> >> >> > > Type "help()" for more information.
> >> >> > >
> >> >> > > But if you delete the last line, it will run fine.
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > > """
> >> >> > > Testing how much memory for python code the microbit has.
> >> >> > > """
> >> >> > >
> >> >> > > from microbit import *
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > >
> display.print("123456789022345678903234567890423456789052345678906234567890723456789082345678909234567890")
> >> >> > >
> >> >> > >
> >> >> > >
> display.print("a12345678902234567890323456789042345678905234567890623456789072345678908234567890923456789")
> >> >> > >
> >> >> > >
> >> >> > >
> display.print("ba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345678")
> >> >> > >
> >> >> > >
> >> >> > >
> display.print("cba123456789022345678903234567890423456789052345678906234567890723456789082345678909234567")
> >> >> > >
> >> >> > >
> >> >> > >
> display.print("dcba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456")
> >> >> > >
> >> >> > >
> >> >> > >
> display.print("ecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456")
> >> >> > >
> >> >> > >
> >> >> > >
> display.print("fecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345")
> >> >> > >
> >> >> > >
> >> >> > >
> display.print("gfecba123456789022345678903234567890423456789052345678906234567890723456789082345678909234")
> >> >> > >
> >> >> > >
> >> >> > >
> display.print("hgfecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923")
> >> >> > >
> >> >> > >
> >> >> > >
> display.print("ihgfecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092")
> >> >> > >
> >> >> > >
> >> >> > >
> display.print("123456789022345678903234567890423456789052345678906234567890723456789082345678909234567890")
> >> >> > >
> >> >> > >
> >> >> > >
> display.print("a12345678902234567890323456789042345678905234567890623456789072345678908234567890923456789")
> >> >> > >
> >> >> > >
> >> >> > >
> display.print("ba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345678")
> >> >> > >
> >> >> > >
> >> >> > >
> display.print("cba123456789022345678903234567890423456789052345678906234567890723456789082345678909234567")
> >> >> > >
> >> >> > >
> >> >> > >
> display.print("dcba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456")
> >> >> > >
> >> >> > >
> >> >> > >
> display.print("ecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456")
> >> >> > >
> >> >> > >
> >> >> > >
> display.print("fecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345")
> >> >> > >
> >> >> > >
> >> >> > >
> display.print("gfecba123456789022345678903234567890423456789052345678906234567890723456789082345678909234")
> >> >> > >
> >> >> > >
> >> >> > >
> display.print("hgfecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923")
> >> >> > >
> >> >> > >
> >> >> > >
> display.print("ihgfecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092")
> >> >> > >
> >> >> > >
> >> >> > >
> display.print("123456789022345678903234567890423456789052345678906234567890723456789082345678909234567890")
> >> >> > >
> >> >> > >
> >> >> > >
> display.print("a12345678902234567890323456789042345678905234567890623456789072345678908234567890923456789")
> >> >> > >
> >> >> > >
> >> >> > >
> display.print("ba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345678")
> >> >> > >
> >> >> > >
> >> >> > >
> display.print("cba123456789022345678903234567890423456789052345678906234567890723456789082345678909234567")
> >> >> > >
> >> >> > >
> >> >> > >
> display.print("dcba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456")
> >> >> > >
> >> >> > >
> >> >> > >
> display.print("ecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456")
> >> >> > >
> >> >> > >
> >> >> > >
> display.print("fecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345")
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > >> Date: Wed, 30 Sep 2015 12:01:57 +0100
> >> >> > >> From: damien.p.george at gmail.com
> >> >> > >> To: microbit at python.org
> >> >> > >> Subject: Re: [Microbit-Python] memory error
> >> >> > >>
> >> >> > >> Hi Alan,
> >> >> > >>
> >> >> > >> Can you post your code?
> >> >> > >>
> >> >> > >> On Wed, Sep 30, 2015 at 2:14 AM, Alan <alainjackson at hotmail.com
> >
> >> >> > >> wrote:
> >> >> > >> > Hi,
> >> >> > >> >
> >> >> > >> > How much memory does the Microbit have for a python program?
> >> >> > >> >
> >> >> > >> > I've written a small program about 105 lines long. It's 3kB on
> >> >> > >> > my
> >> >> > >> > hard
> >> >> > >> > disk.
> >> >> > >> > It runs ok now but when it was 115 lines long and 3.2kB I kept
> >> >> > >> > getting
> >> >> > >> > memory allocation errors as soon as I pressed the reset
> button.
> >> >> > >> > If
> >> >> > >> > I
> >> >> > >> > commented about 10 lines out of my program it would run and it
> >> >> > >> > didn't
> >> >> > >> > seem
> >> >> > >> > to matter which 10 lines. So I assumed it was out of program
> >> >> > >> > memory?
> >> >> > >> >
> >> >> > >> > Cheers,
> >> >> > >> >
> >> >> > >> > Alan
> >> >> > >> >
> >> >> > >> > _______________________________________________
> >> >> > >> > Microbit mailing list
> >> >> > >> > Microbit at python.org
> >> >> > >> > https://mail.python.org/mailman/listinfo/microbit
> >> >> > >> >
> >> >> > >> _______________________________________________
> >> >> > >> Microbit mailing list
> >> >> > >> Microbit at python.org
> >> >> > >> https://mail.python.org/mailman/listinfo/microbit
> >> >> > >
> >> >> > > _______________________________________________ Microbit mailing
> >> >> > > list
> >> >> > > Microbit at python.org
> >> >> > > https://mail.python.org/mailman/listinfo/microbit
> >> >> > >
> >> >> > > _______________________________________________
> >> >> > > Microbit mailing list
> >> >> > > Microbit at python.org
> >> >> > > https://mail.python.org/mailman/listinfo/microbit
> >> >> > >
> >> >> > _______________________________________________
> >> >> > Microbit mailing list
> >> >> > Microbit at python.org
> >> >> > https://mail.python.org/mailman/listinfo/microbit
> >> >>
> >> >> _______________________________________________
> >> >> Microbit mailing list
> >> >> Microbit at python.org
> >> >> https://mail.python.org/mailman/listinfo/microbit
> >> >>
> >> >
> >> >
> >> > _______________________________________________
> >> > Microbit mailing list
> >> > Microbit at python.org
> >> > https://mail.python.org/mailman/listinfo/microbit
> >> >
> >> _______________________________________________
> >> Microbit mailing list
> >> Microbit at python.org
> >> https://mail.python.org/mailman/listinfo/microbit
> >>
> >>
> >>
> >> _______________________________________________ Microbit mailing list
> >> Microbit at python.org https://mail.python.org/mailman/listinfo/microbit
> >>
> >> _______________________________________________
> >> Microbit mailing list
> >> Microbit at python.org
> >> https://mail.python.org/mailman/listinfo/microbit
> >>
> >
> >
> > _______________________________________________
> > Microbit mailing list
> > Microbit at python.org
> > https://mail.python.org/mailman/listinfo/microbit
> >
> _______________________________________________
> Microbit mailing list
> Microbit at python.org
> https://mail.python.org/mailman/listinfo/microbit
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/mailman/private/microbit/attachments/20151003/f59e42b2/attachment-0001.html>

More information about the Microbit mailing list