Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > C64 Coding > Packer vs Code VM vs Code Generator
2016-08-13 16:38
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?
 
... 80 posts hidden. Click here to view all posts....
 
2016-08-23 07:33
Krill

Registered: Apr 2002
Posts: 2980
Once upon a time, AEG was working on a VM for a 4K demo of his, which, to my knowledge, was never finished. It implemented 32-bit arithmetics (including MUL and DIV) via an orthogonal instruction set operating on virtual registers.

I wonder if for a purpose like that, a stack machine approach similar to Intel's 8087 would be suited well.
2016-08-23 08:52
White Flame

Registered: Sep 2002
Posts: 136
Having played with a bunch of VM strategies on the 64, I'd say that a stack machine is nice for numeric evaluation, but not for general purpose use. If you're only going to have one or the other, I'd stick with some notion of register file.
2016-08-23 13:57
Frantic

Registered: Mar 2003
Posts: 1648
I once coded a 6510-emu routine to be run on C64. :D Sounds like one of the more reasonable things to do, right? ;)

It actually executed the instructions, one after another, setting/restoring cpu flags and such, but it checked some constraints before and after executing the opcodes.

(The purpose was to be able to execute randomly generated 6510 code, but to be able to disallow access to certain memory areas and stuff like that — e.g. to avoid crashes. It was related to some experimentation with Genetic Programming.)
2016-08-23 16:47
Krill

Registered: Apr 2002
Posts: 2980
Frantic: Interesting! Did your evil experiments go anywhere? What did you train the software for? What were the fitness functions? After which generation did the software do anything noteworthy? Did it become self-aware? :)
2016-08-23 17:25
Oswald

Registered: Apr 2002
Posts: 5094
frantic you could have just insterted a brk _before_ each instruction, and the irq woul have examined it if its within limits :)
2016-08-23 17:27
Frantic

Registered: Mar 2003
Posts: 1648
Hehe.. Yes, I pulled the plug and stopped being active in the scene when the C64 threathened to kill me.

Well.. No, I didn't get very far. If I remember correctly I think Alih came up with some "code a c64 game" competition that I made a small game for instead of continuing with the 6510-emu thing. That game was also based on similar evolutionary principles, but I didn't make it before the deadline, so I just stopped. It was released as a preview by Triad though, a whole bunch of years later:
Drone Processor Preview

From an evolutionary perspective that game is not very interesting though, as it was precisely that part was what needed some work. So not much came out of that either. :D That game didn't generate 6510 code though, but I just made some sort of simple VM without much thought at all behind it. Just fiddling around for fun.

...and then I coded defMON instead. :)
http://toolsforscholars.com/defmon/doku.php
Defmon &D

Sorry for being off topic.
2016-08-23 17:34
Frantic

Registered: Mar 2003
Posts: 1648
Oswald: I guess I could have done that, but if I remember correctly I didn't want to insert anything in the code. I wanted it to have precisely the form it would have when being executed for real, so that — potentially — an opcode could be used as an operand and vice versa, depending on where things branched, and that it could self modify in whatever way (as long as it stayed within its workspace, so to speak) during the execution, and so forth...
2016-08-23 18:05
Digger

Registered: Mar 2005
Posts: 437
A little off-topic but I remember MARS being implemented in Core Wars (http://www.koth.org/info/corewars_for_dummies/dummies.html)

It would be cool to run some OOP on C64 as TBH suggests :)
2016-08-24 10:25
ChristopherJam

Registered: Aug 2004
Posts: 1409
In terms of making more compressible code, I wonder if it would be worth normalising most or all instructions to three bytes long?

A table of all the numbers from 0 to 255 on page $ea would let you turn all immediate operands into absolute, while padding all branches with the same third byte as the immediates. There would be fewer distinct opcodes in the stream to be compressed, too.

Of course, that still leaves the single byte instructions. Pack these into groups of one to three opcodes, padded with a nop or two?
2016-08-24 15:14
Krill

Registered: Apr 2002
Posts: 2980
I'm sceptical. Assuming it would pay off in terms of compression ratio, you'd end up with either pretty inefficient code or rather expensive decoding (in terms of size, to recover the original 1- or 2-byte instructions).
Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
Flashback
Bieno/Commodore Plus
DeMOSic/MS^LSD^ONS
Guests online: 83
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Mojo  (9.7)
4 Coma Light 13  (9.6)
5 Edge of Disgrace  (9.6)
6 What Is The Matrix 2  (9.6)
7 The Demo Coder  (9.6)
8 Uncensored  (9.6)
9 Comaland 100%  (9.6)
10 Wonderland XIV  (9.6)
Top onefile Demos
1 Layers  (9.6)
2 No Listen  (9.6)
3 Cubic Dream  (9.6)
4 Party Elk 2  (9.6)
5 Copper Booze  (9.6)
6 Rainbow Connection  (9.5)
7 Dawnfall V1.1  (9.5)
8 Onscreen 5k  (9.5)
9 Morph  (9.5)
10 Libertongo  (9.5)
Top Groups
1 Performers  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Triad  (9.3)
5 Censor Design  (9.3)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.067 sec.