| |
oziphantom
Registered: Oct 2014
Posts: 490 |
Packer vs Code VM vs Code Generator
Has anybody experimented with/know of code VMs or Generators.
Just thinking to get code size down they might perform better than exomiser et al.
I know of Sweet16 by Woz any others? |
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
i decent code generator will always win. unless speed doesnt matter much, then you can gain a lot by using some kind of interpreted VM (most obvious example: the basic interpreter) |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: Has anybody experimented with/know of code VMs or Generators.
Just thinking to get code size down they might perform better than exomiser et al.
I know of Sweet16 by Woz any others?
The vectors in our 1991 demo uses a VM do encode the generated code for each object. It outperforms a general cruncher in both size and speed since it's tailored to the problem domain. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
I think its stretching to call VM a data set that describes how to generate code. but prove me wrong :) |
| |
Claus_2015
Registered: Oct 2012
Posts: 53 |
I would say this obviously strongly depends on the properties of the data that needs compression. If any kind of simple rule can be applied, code/data generation is probably the way to go. If the data consists of permutations of non-trivial functional elements a VM is probably good. If no suitable property can be found, a generic compressor might be the only way out. Different parts of the compressed data might have different properties, so combining all of these might be the best solution. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: I think its stretching to call VM a data set that describes how to generate code. but prove me wrong :)
True, it's just opcodes that selects data chunks together with parameters for altering the data written. |
| |
White Flame
Registered: Sep 2002
Posts: 136 |
I've used this VM for some tool development. I've got a v2 that isn't pushed to github that I need to finish. Speed hit is under 10x slower than asm for degenerate cases, which is pretty good for this field, and it's intended for the user to add large heavyweight instructions to it which basically makes it as fast as you want.
http://acheronvm.github.io/acheronvm/ |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting oziphantomHas anybody experimented with/know of code VMs or Generators.
Just thinking to get code size down they might perform better than exomiser et al.
I know of Sweet16 by Woz any others? As has been said before, specially-made code generators do indeed outperform generic compressors in terms of compression ratio and decompression speed. Just look at any effect-driven small-size demo (4k, one-filers) worth its salt. (Using code generation first and then generic compression later.)
VMs aren't encountered as often in demos as they are in games (which you might be going for), as they usually execute much slower than native code, but have a smaller memory footprint. Of course, they may compile to native code at run-time, as in Jackasser's example, which is a form of code generation again. For efficient 6502 VM techniques, you might want to take a look at http://codebase64.org/doku.php?id=base:dispatch_on_a_byte . |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting OswaldI think its stretching to call VM a data set that describes how to generate code. but prove me wrong :) Quoting JackAsserTrue, it's just opcodes that selects data chunks together with parameters for altering the data written. Quoting WikipediaVirtual machines operate based on the computer architecture and functions of a real or hypothetical computer. I think Jackasser's example can be considered a VM on the semantic level, and that the implementation details are irrelevant, no matter how trivial.
Just like i think context-switching via interrupts on 6502 is a threading implementation and the KERNAL is an OS.
Really, the definitions are vague on those, and the general concepts can be applied to all computing machines, even at the lowest end. |
| |
oziphantom
Registered: Oct 2014
Posts: 490 |
Quoting KrillQuoting oziphantomHas anybody experimented with/know of code VMs or Generators.
Just thinking to get code size down they might perform better than exomiser et al.
I know of Sweet16 by Woz any others? As has been said before, specially-made code generators do indeed outperform generic compressors in terms of compression ratio and decompression speed. Just look at any effect-driven small-size demo (4k, one-filers) worth its salt. (Using code generation first and then generic compression later.)
VMs aren't encountered as often in demos as they are in games (which you might be going for), as they usually execute much slower than native code, but have a smaller memory footprint. Of course, they may compile to native code at run-time, as in Jackasser's example, which is a form of code generation again. For efficient 6502 VM techniques, you might want to take a look at http://codebase64.org/doku.php?id=base:dispatch_on_a_byte .
I'm thinking Game. Reset 4K ;) I want to do scrolling and at the moment the smallest way is for me to make a simple code unroller to do LDA STA pair to shift CRAM and SCREEN ;)
But doing common things like
LDA #00
STA $08
LDA #$80
STA $09
could be LS16 08 80 00 = 4 bytes vs 8
LDA $FC
CLC
ADC #06
STA $FC
could be ADCI FC 06 = 3 bytes vs 7
IO needs 6 bits to say what register is needed max, 2 bits to specify VIC,SID,CIA1,CIA2 so you can make
LDA #$7F
STA $D015 = 5 bytes
into
ST VIC15 7F = 3 bytes
LDA $D015
AND #$7E
STA $D015 = 8 bytes
AND VIC15 7E = 3 bytes
I would think a 4K game( maybe even a 1Meg game ) you could fit most Variables into 256 bytes. I normally put them at $200 so I could have a bit in a Command byte that specifies that the next store/load is Variables and hence the next byte is really $02XX
With flags a STZ or Store 1 would also probably be handy
to which STZ XX for zero page is 2 bytes. STZV XX for variables is also 2 bytes.
LDA CMP BXX chains could be dropped to LCBXX AA BB CC
Where the game would be unpacked with exomiser, then the code packer would parse the code bytes to spit out the expanded code, then the game would be run.
But it could all work out worse in the end. Curious to know what people already had/have tried and failed etc. |
| |
oziphantom
Registered: Oct 2014
Posts: 490 |
Quoting KrillQuoting OswaldI think its stretching to call VM a data set that describes how to generate code. but prove me wrong :) Quoting JackAsserTrue, it's just opcodes that selects data chunks together with parameters for altering the data written. Quoting WikipediaVirtual machines operate based on the computer architecture and functions of a real or hypothetical computer. I think Jackasser's example can be considered a VM on the semantic level, and that the implementation details are irrelevant, no matter how trivial.
Just like i think context-switching via interrupts on 6502 is a threading implementation and the KERNAL is an OS.
Really, the definitions are vague on those, and the general concepts can be applied to all computing machines, even at the lowest end.
To me if
the code is ran once, then it is a code generator
the code reads data, makes code, runs it, comes back reads more data, makes code, runs it ... then it is a JIT VM |
... 80 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 - Next |
