[Microbit-Python] memory error
David Whale
david at thinkingbinaries.com
Sat Oct 3 08:41:20 CEST 2015
:)
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" <http://amzn.to/ZGfxZG>
- 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"
> <http://amzn.to/ZGfxZG> - 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/mailman/private/microbit/attachments/20151003/d1ca1b19/attachment-0001.html>
More information about the Microbit
mailing list