S3G is binary version of gcode. In other words, if you know anything about what happens with an 8 bit microcontroller (or really any microcontroller) sending ASCII text via a serial link, nothing else can happen until the data is finished transmitting. In other words, you motion control STOPs dead with pauses until the entire ASCII string is sent. Thus, the idea behind the binary compression which greatly reduces the CPU time. When you print with rep-g across USB, ever notice the pause before the machine even tries to home or do anything? That is rep-g converting the text gcode to S3G as a temp file before it sends it to the bot across the USB. ALso, for massive performance increases, we can save the S3G to the SD card and reduce the latency and thus tiny pauses during the print that cause little zits.
Thus to be perfectly clear, S3G is a compressed version of the created gcode, and since the gcode has the homing and other bot specific info in the start and end portions, not easily tranportable between machine variants. Also, I don't know that you can ever go from S3G back to text gcode. In other words, it's one way compression for most usage. The gcode interpeter in the firmware reads it as commands, but I don't think you could use that to convert it back to text as a C++ application on the PC.
