JM-15S - feedback welcome
|
08-05-2014, 05:58 PM
(This post was last modified: 08-05-2014 06:03 PM by jwm.)
Post: #11
|
|||
|
|||
RE: JM-15S - feedback welcome
(08-05-2014 04:26 PM)Marcus von Cube Wrote: The WP 34S battery saving algorithm is based on turning the core off while the device is waiting for a key. The same holds for HPs firmware for the same chip (10bii+, 12C+, 15C LE, 20b/30b). This saves a lot of energy but it looses the 4KB RAM between keystrokes. Your GC would be quite busy if you were doing it in a similar way. Running the GC would probably cost more then turning the chip off could save. Well, the main reason for the GC is not to get things into that 2k, but to give them a much smaller representation and only spend time and cycles on things that will last a while. Most values are consumed right after they are produced, so coming up with a compact memory footprint isn't important and can cost extra cycles to pack and unpack values, however, some are long lived and end up as part of programs or stored in registers. There is a tension between these two desires for a compact representation and an easy to work with one, that a compacting/optimizing GC can solve. It only takes the extra effort to come up with compact representations for things that are going to live a while, but the hundreds of thousands of intermediate values do not need to be reclaimed and can be stored in memory in their most efficient to manipulate representation. The GC before shutting down the core can be very fast, the invarient that pointers from saved ram can only point to saved ram or flash, and flash can only point to flash, means that as soon as we see a pointer into something other than dynamic ram we can stop. meaning that in almost all cases during normal usage, the GC will go no further than the few values on the stack itself because everything else will have been commited to long term storage on a previous GC and all the intermediate results of calculations done are simply discarded and not traversed. It will occasionally have more to do, such as when the 2K itself is filled and it needs to clean house with a full GC or move things to flash, but that will be exceedingly rare, only after some dedicated programming or data entereing time when there is more that actually needs to be saved. So, it will still GC and shut down between keystrokes, which will likely just store a single stack value and not traverse any further, but during the execution of programs it will have the full 6K to scribble on. Quote:Are you planning an emulator so that more people will try the user interface? Very probably. The core is based on a language that already is a standalone linux program. I'd actually like to make the emulator be in the form of an android app. Since that will be just useful in general, but it has been a while since I have done android programming, will have to look into it. Everything will be open sourced of course. John John Meacham - http://notanumber.net/ |
|||
« Next Oldest | Next Newest »
|
Messages In This Thread |
JM-15S - feedback welcome - jwm - 08-04-2014, 05:05 AM
RE: JM-15S - feedback welcome - walter b - 08-04-2014, 06:31 AM
RE: JM-15S - feedback welcome - jwm - 08-04-2014, 08:41 AM
RE: JM-15S - feedback welcome - jwm - 08-04-2014, 07:21 PM
RE: JM-15S - feedback welcome - walter b - 08-04-2014, 08:06 PM
RE: JM-15S - feedback welcome - jwm - 08-05-2014, 02:54 AM
RE: JM-15S - feedback welcome - walter b - 08-05-2014, 06:02 AM
RE: JM-15S - feedback welcome - Marcus von Cube - 08-05-2014, 04:26 PM
RE: JM-15S - feedback welcome - jwm - 08-05-2014 05:58 PM
RE: JM-15S - feedback welcome - JimP - 08-05-2014, 01:45 AM
RE: JM-15S - feedback welcome - jwm - 08-05-2014, 02:42 AM
RE: JM-15S - feedback welcome - Jake Schwartz - 08-06-2014, 08:01 PM
|
User(s) browsing this thread: 1 Guest(s)