| |
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....
|
| |
Trash
Registered: Jan 2002
Posts: 122 |
Quote: Quoting JackAsserSpeaking about getting laid. I think you HCL have the highest CSDB Code score / number of kids ratio (C2K^-1) actually. Except... how is having kids related to getting laid... on a highly frequent basis? I demand some _scientifically sound_ facts! :D
Having children is nothing but proof that their mother is getting laid, not that you are... ;-) |
| |
oziphantom
Registered: Oct 2014
Posts: 478 |
Mothers are sceners too. |
| |
Oswald
Registered: Apr 2002
Posts: 5022 |
back to topic, reread ozi's post, and actually I find it a cool idea.
kickass would suit nicely for this, but one problem I see is how one would compile this so, that adresses are correct after code is blown up to normal size. illegals should be used for the pseudo instructions. maybe I'd use a macro which adds enough nops after "own" instructions to keep the code size same for adresses to work, then a preprocessor would remove the nops. |
| |
oziphantom
Registered: Oct 2014
Posts: 478 |
I've made macros, but the tass64 verbose option doesn't list when it "invokes" one. As I was thinking you could assemble with the macros expanded, this will give you a labels file with all the correct placements. Then run through the listing and pack the macros.
Maybe a post process that just hunts the code for patterns and then applies the patterns as it finds it, use macros to "enforce" a pattern is the best way to go. |
| |
Krill
Registered: Apr 2002
Posts: 2851 |
Quoting Oswaldkickass would suit nicely for this, but So it's not suited nicely :) Really, it amazes me when people try to shoehorn in stuff that, in this case, the tool really wasn't built for (just a guess, though). You'd fare better with the standard approach of writing your own standalone encoder and decoder. However, i still reckon the gain is rather poor in comparison to other approaches, at least when having to provide the decoder in the same binary. |
| |
Krill
Registered: Apr 2002
Posts: 2851 |
Thinking further about it, it may be a better approach to decrease code density rather than increase it.
As the program will ultimately be compressed with a general-purpose compressor anyways, you want to support it. In the case of code, that'd mean a more regular structure, with a lot of repeating or similar sequences.
So you'd "RISCify" the code, meaning to come up with an orthogonal set of instructions: INC a, INC x and INC y will all have the same op-code, but different arguments. Together with the separated op-code and argument streams i mentioned above, this might pay off.
Of course, again, there is a rather high initial cost for the decoder, which may or may not amortise in 4K, plus the code will probably perform (slightly?) worse compared to highly optimised hand-crafted native code. |
| |
Mixer
Registered: Apr 2008
Posts: 422 |
In my opinion 1K and 4k and other small space code challenges are more about redefining the problem than making a language or VM.
I like this Krill's idea of opcode stream and arguments stream. It is like having two stacks of data that one combines into a program. I don't think it has 4k benefits, but as a way to "stream" or VM programs it is interesting. |
| |
Krill
Registered: Apr 2002
Posts: 2851 |
It DID have benefits in Artefacts. And trust me, there was a lot of trial and error before i settled for that one (and some other techniques). :) |
| |
Oswald
Registered: Apr 2002
Posts: 5022 |
there's a lot more going on in artefacts I've thought, kudos :) |
| |
oziphantom
Registered: Oct 2014
Posts: 478 |
I though about simplistic code, I think the macros will actually help there as well for just normal compression but the issue I see is this
LDA #7f
STA $d015
LDA #0
STA $d027
LDA #84
STA $43E7
At this point the compression gets an LDA, unique number, STA, unique number, D0 LDA, unique number, STA, unique number, D0 LDA, unique number, STA unique number, unique number. To which I feel that by the time the compression system encodes the custom byte stream, and then the 2 byte pairs, then back to custom, then 2 bytes, it would actually consume more memory than taking the whole lot as a custom stream. Using the conventional wisdom I know Code compresses badly, data compresses well, make more data.
Any code that is mostly the same, will be JSR optimised by the coder, so you just end up with the annoying sequences that its not worth the extra instructions to jsr as you end up with a loss.
+ lda $3
bne +
dec $4
+ dec $3
lda $6
bne +
dec $7
+ dec $6
So close, yet so far.
Which I think is proven by Krill's genius idea of splitting data and code this way you would get a nice run of
LDA STA LDA STA LDA STA and just pay for the 7f 15 d0 00 27 d0 84 e7 40
Wether or not the code expansion system pays-off in 4K is hard to tell until all the chips are on the table. It might only be viable at 16K. I fell that for things like Demos that have highly algorithmic based effects and code that the split will pay off very well, as you will do lots of similar code, while a game tends to have large amounts of unique code with random structure. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 - Next |
