| |
oziphantom
Registered: Oct 2014
Posts: 478 |
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? |
|
... 80 posts hidden. Click here to view all posts....
|
| |
Krill
Registered: Apr 2002
Posts: 2851 |
Ah, sorry, didn't read thoroughly enough.
But i guess the compressor itself should be oblivious to the semantic details of the blob you serve it. It should not know about op-codes/arguments/data separation and just crunch everything as well as it can.
It should be served data it can compress well, and this is where any special coding takes place before final compression and after initial decompression.
In principle this is akin to Burrows-Wheeler transform/move-to-front, which makes it much better compressible. |
| |
Krill
Registered: Apr 2002
Posts: 2851 |
Quoting JackAsserIt would be very slow, but couldn't you depack that stream without a table! :) Imagine placing a BRK after the opcode in the stream then use the IRQ to determine the opcode length by checking the pushed PC on the stack! Sneaky! Excellent idea! However, i have a hunch that the code for all that would, in the end, still consume more compressed data than the rather straightforward approach with a table, which is probably better to compress. Not to speak of execution hazards with funny op-codes in an environment that doesn't really allow for sandboxing. :) |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: Quoting JackAsserIt would be very slow, but couldn't you depack that stream without a table! :) Imagine placing a BRK after the opcode in the stream then use the IRQ to determine the opcode length by checking the pushed PC on the stack! Sneaky! Excellent idea! However, i have a hunch that the code for all that would, in the end, still consume more compressed data than the rather straightforward approach with a table, which is probably better to compress. Not to speak of execution hazards with funny op-codes in an environment that doesn't really allow for sandboxing. :)
Indeed, it's a bit tricky, but possible. For instance RTI/RTS handles the return address a bit different (+1 vs -1). But I guess having argument $02,$02 and then prefill the stack return address properly should be able to handle most degenerate cases. But yeah, it's a big chance it will compress worse in total tbh. |
| |
Oswald
Registered: Apr 2002
Posts: 5022 |
"RTI/RTS handles the return address a bit different "
wot ? didnt knew this. why ? |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: "RTI/RTS handles the return address a bit different "
wot ? didnt knew this. why ?
Dunno, but it does. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11131 |
iirc there was a longish thread explaining it on 6502.org |
| |
Krill
Registered: Apr 2002
Posts: 2851 |
Quoting Oswald"RTI/RTS handles the return address a bit different "
wot ? didnt knew this. why ? Why, because JSR pushes the return address MINUS 1 on stack while an interrupt simply pushes the return address, of course. :D
But seriously, as groepaz implied, the reason for that is likely due to some 6502 design intricacies. Something like JSR pushing next op-code minus 1 because PC at that stage isn't incremented yet to the next op-code, while interrupts are handled exactly between op-codes (after increasing PC). |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: iirc there was a longish thread explaining it on 6502.org
Ahh ok, didn't know. I was painfully aware of it when I implemented my preemtive multitasking to support yeild (i.e. give up CPU to another thread). Normally the task-switch is performed by some interrupt (i.e. the return / continuation point for the thread is placed on the stack and resumable with an RTI). However, when I want to yield in "userspace", i.e. not wait until the next task switch, the task switch is performed by a subroutine and thus resumable with an RTS. So I need to keep that in mind so that I don't accidentally mix up those to types of resume possibilities. Basically the yield-call manipulates the stack to convert it from RTS-compatible to RTI-compatible by adding to the return address and push the status also. Hairy, but it works... :) (And it's useless, but fun!) |
| |
Krill
Registered: Apr 2002
Posts: 2851 |
Why didn't you use BRK, which was basically invented for things like this? :) (It's the 6502 equivalent of TRAP.) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11131 |
brk is more useful for systemcall type of things, not "yield" imho |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 - Next |
