pouët.net

i'm getting back into demoscene-ish coding after years and years of absence.. it's 20 years since my first release, so i'm thinking about a kind of 'celebration' thing.. unfortunately, my ancient handle 'axon' (xenon dev/excess/inf) was taken, so i had to register with a new one.. buhu.. :-/ but, to the point: does anybody have experience or knowledge about the 'innards' of the freepascal compiler? i'm trying to trim down my 4k (and possibly 1k?) framework, and have gotten it down to 864 bytes for a do-almost-nothing exe, compressed with bero's exe packer, and just above 2k with some simple test opengl/texgen/drawing/synth/audio/codegen .. but i still think there's potential for shaving off more bytes, with more specific system-unit replacements, or compiler/linker flags (or even tweaking the compiler itself)..
anybody?

i'am using crinkler for compression , its better than bero one , i got ~500b for messagebox app , and ~800b for a simple window app . ~1.2kb for window+ogl+shader

freewilly

Isn't (Object) Pascal a .NET language now? That might be a more valuable approach for size. Otherwise, Pascal was never a draw for size coders, because the old wisdom was that no amount of fiddling with compiler settings will get you down to C or ASM levels. Probably still holds true.

@axxxon:
I never tried to shrink FPC executable size to that extreme, and especially not on Windows, but I ported Free Pascal 2.x to Amiga (and others), so I happen to know some stuff about compiler and RTL internals. Far from everything though, but maybe something. :) So if you have anything specific, feel free to ask? I can't come up with recommendations by myself because what I would have as first ideas you're probably way beyond that point already. :)

@tomaes:
No, it's not. Free Pascal generates standalone native executables, nothing to do with .NET. With FPC, you can also easily can use your own ultra-small custom system/etc unit implementations, skipping most of the high-level Pascal language support stuff you shouldn't need in a 4K intro anyway. If you say sizecoding is not possible in Pascal, is just about as silly when coders with "old wisdom" said 4K intros in C were impossible, HW accelerated 4Ks were impossible, etc...

In 1k intros, you need to go 100% asm to squeeze out the final bytes. Keeping parts in a high level language is a waste, at least if you're using Crinkler. I can't think of a way to make a compiler produce the sort of bizarre instruction combinations that ultimately produce the smallest packed size. Even though in theory a compiler would be just the right tool for trying out all possible instruction combinations with brute force. But until someone creates that byte masher compiler, asm is the best choice.

Yeah, well, 1Ks are a different matter indeed, but 4Ks should be possible just about the same way they're possible in C.

Then again, FPC might not be the worst starting point if someone wants to create a size optimizing compiler. Has anyone tried using it with Crinkler? In order for the size optimizing brute force mashing to work, FPC's own internal linker would have to replaced with Crinkler.

Read carefully. I said that .NET might be an interesting way to go, so you can use the .net infrastructure and hence get smaller executables (just a thought, really). Sure, there are native Pascal compilers for all sorts of platforms since the 1970s and you can rewrite crt/system units in ASM and whatnot, but the fact back then was (and likely still is) that getting a proper exe below a certain threshold is a pain in the neck compared to other, more suitable options.

...or if you don't want to go brute force all the way - and since the number of possible instruction combinations would be astronomically high, it wouldn't be feasible anyway - you could try at least implementing some sort of heuristics, like "do everything with the stack and avoid using registers as much as possible".

Recent versions of FPC do support a "optimize for size rather than speed" command line switch:
I'm not sure of the "size gains" with that, tough.

"Optimize for size" optimizes for uncompressed size, and in tiny intros you care about compressed size. AAAAAAAAAAAAAAAAAAAA is better for final size than ABCD.

@tomaes:
No, you can't go with .NET in FPC. CRT unit is deprecated for 20 years, no one uses it any more (except for compatibility, which is not the case here). All you need is a system unit replacement, really. You can even write it in Pascal, compile with -Us when compiling it. You can also use inline assembly more comfortable than in most C environments, so you don't need to mess with an external assembler.

@yzi:
There's an option to add external linkers to FPC. It's pretty easy. I don't know a lot about crinkler, but it should be possible. In fact, most platforms use external linkers, because the internal one is not available everywhere. On Windows, there's still an option to use GNU LD instead of the internal linker, so the GNU LD support is probably a good starting point to add another external linker.

c is possible so a nice 4k in pascal should be possible too (there are 4k in pascal here at pouet including source). can't say anything on the topic regarding internals of the compiler or how your code is :)

1k or 4k ... as long as it is nice :)

What is your obsession with FPC? I'm explicitly not talking about FPC. :P

The bottom line remains that using vanilla x86 Pascal to make a non-trivial 1k (or any 1k, really) is rather foolish. And 4k is not a big challenge. Those things have been done before on DOS and Windows. The End. :)

@tomaes:
I'm obsessed with FPC because 1., look at the topic title 2., I'm a member of the FPC Development team. :) The End.

sensenstahl: C is portable Assembly. Pascal is not. (If there's some awesome hack to get the same thing in Pascal without a custom compiler, I like to see it. :P)

...what

Turbo/Object Pascal is a very nice language, and FPC is a great compiler that can make good code for an incredible array of target platforms.

However, knowing how little x86 code there is in modern 1k intros, ... Unless you're using a generative music routine (that creates the MIDI messages in code rather than just playing back a premade MIDI event sequence), like I have in all of my 1k intros so far, there's almost no logic at all. Apart from the unpacking stub/loader (like Crinkler or Laturi), the only x86 code you want to have (and we have yet to see impressive PPC or ARM 1k intros), is just filling parameters for API calls.

Charlie: So what makes the "bloat" in the binary? (in native Pascal compilers in general) Memory management / safety of allocations / (lack of) ties to the OS? I like to know. :)

Gargaj: Yeah, kind of "unsave" statement? I was going for the memory management angle. ;)

tinyC gives a little executable.

@tomaes:
Well, the default RTL (Runtime Library) has its own memory manager (much like libc), and a shitload of support functions for strings/math/etc (much like libc), basic file and I/O functions (much like libc), threading (ok, you need pthreads/native API here with C), and a few others. If you don't use these, you can come up with your own "stub" library, which is empty and skip most of the bloat. You can map your memory, string and file I/O functions directly to OS functions, if you still need them, or just use OS calls directly, then you don't even need to have most of them in your System unit replacement. Obviously you'll lose some language features like reference counted strings. But these are optional anyway (in FPC at least, in the default compiler mode). FPC can generate native C-style (WINAPI-stlye, whatever-style) calls OS functions, there's no additional "wrapper" code involved, so it's your "portable assembler" just fine in this case.

FWIW, I made these two 4k intros with a 1k base structure, just replacing MIDI music with 4klang, which was done in asm as well. All the demo logic that's in x86 code is just incrementing the frame counter, and I don't think C or Pascal gives any benefit there. All of the actual logic is in GLSL. I thought that was a nice and productive way to code.

Actually, the internal linker (on Windows at least) will try to do "smart" linking and not link any of the unused functions from the units it links. Still, there's quite a lot of stuff which can be striped. But if you're down to a 800 bytes binary size, you're probably deep into this already anyway. ;)

Note that using .net is not allowed according to many size compo rules.