[BAILOPAN]

For AMX Mod X, we will be distributing a new hybrid compiler called AMXXSC.
Plugins compiled in this new compiler will be named ".amxx" instead of ".amx", although AMX Mod X can still read .amx files. This new format is for 64bit compatibility. 64bit AMX Mod X can only read the new format.

AMXXSC is a wrapper for dynamically linked versions of the Small 2.5.1 compiler, which is an unreleased version of 2.5.0 that has many bug fixes. This compiler is a hybrid of a 32bit compiler and a 64bit compiler, and outputs files in a new format called ABL (Abstract Ball).

Abstract Ball is a format for storing multiple architectures of AMX plugins. It can hold the bytecode for 8, 16, 32, 64, 128, and 256 bit plugins. For AMX Mod X 0.20, the 32bit code is stored with compact encoding and the 64bit section is stored without compact encoding. Both sections are compressed with Lempel-Ziv-Oberhumer-1 compression.

For those interested, it is structured like this:

MAGIC (0x[RLEB]) [long/uint32]
# of Architectures [byte]
ArchHeaders[#]: 
   Cellsize [byte]
   Stack size [long/uint32]
   File offset [long/uint32]
ByteCodes[#]:
   LZO(CellBytecode) - []

Surprisingly, even though the amount of data is essentially doubled, plugins will often decrease in size under the new format.

--UPDATE--
The format for 0.20 versions >= TP3 is now "AMXBall". The magic is AMXB and the compression is gzip.

[devicenull]

Wtf is Lempel-Ziv-Oberhumor-1 compression?

[kingpin]

oberhumor? Bailo comon man April 1st passed a while ago...

[BAILOPAN]

It's the oberhumer variation of the Lempel-Ziv algorithm ;]

http://www.oberhumer.com/opensource/lzo/

[PM]

It is oberhumer, isn't it?

[Wraith,]

I'm assuming those types are from c, and not some other language in which the type lengths may differ. Can i suggest that you simply refer to them like int64 or uint32 instead of relying on me to work out what lengths they are supposed to have?

Whats a list[] when its at home? how is that represented in the file itself? do you just mean concatenated segments? If so then your notation seems a little confusing to me.

as for LZO, well we've already talked about this. But even RLE would have removed a good portion of the zero'ed space, why lzo, whats wrong with good old gzip .

[BAILOPAN]

Okay there Wraith,, I have updated it to appease you

RLE would offer almost no benefit on 32bit+CE and very little benefit on 64bit-CE. I didn't use GZ because I liked LZO on first sight, it looked fast and I could understand it.

Originally we were gonna use RLE, which is why the magic header stands for "RLEBall".

[Wraith,]

I did wonder about that, i thought you'd have gone with {41,4d,58,58}
Appease? Me? I'm still surprised when people listen.

[BAILOPAN]

I didn't feel like typing out the hex ;]

[heretic]

Originally Posted by BAILOPAN Surprisingly, even though the amount of data is essentially doubled, plugins will often decrease in size under the new format.

Does the Small compiler use the extra registers? I'm assuming it does since it uses a new VM to execute the 64-bit Small bytecode. The extra registers typically shorten the number of instructions by drastically reducing load/stores. This comes with a cache benefit in addition to increasing the IPC. The code executes faster because of ISA tweaks in amd64 but you take the hit with data because odds are you have a lot of data addresses. Then again, you get benefits from the virtual memory tweaks of the ISA which probably negate those effects. Overall, moving to the x86-64 ISA is a complete win, it fixes everything that was wrong with x86.

It's nice to see software for this coming along. Not that we'll ever see a ns64.so, it's still cool.