Move 1988-2004 entries into subdirs
We we move 1988-2004 entries from all of a year's winning entries in a single directory to each winner being in their own sub-directory under the given year directory.
This commit is contained in:
Landon Curt Noll committed
1 parent
1e82e8aa3e
commit
d2a42f42e8
478 files changed
No files matched your search
@@ -0,0 +1,39 @@
|
||||
#define processor x86
|
||||
|
||||
#include <stdio.h>
|
||||
#include <sys/stat.h>
|
||||
|
||||
#define l int*
|
||||
#define F char
|
||||
struct stat t;
|
||||
#define c return
|
||||
#define I (P+=4,*L(P-4,0))
|
||||
#define G (signed F)E(*L(P++,0))
|
||||
#define C(O,D)E (D[B+V(010)/4+O*10])
|
||||
#define U R[4]=E(V(17)-4),*(l)V(021)=
|
||||
F M [99],Q[99],b[9999],*ss,*d=b,*z;
|
||||
#define O =(n=*(l)V(021),R[4]=E(V(17)+4),n)
|
||||
#define p(a,b,c) system((sprintf(a,b,k[1]),c)),z
|
||||
#define g (y/010&7)
|
||||
#define R (B+13)
|
||||
#define x86 (F*)index\
|
||||
(ss+V(i ),0100)
|
||||
#define D(y,n,a,m,i,c )d+=sprintf( d,y,n,a,m,i,c ),(F*\
|
||||
) P
|
||||
l B,i,n,a,r,y ,
|
||||
P ;
|
||||
#define Tr(an,sl,at,or) l an##i(d,sl){ c at? an##i(d,r):or; } \
|
||||
l an(d, sl){ c \
|
||||
r=V(014 )&63,an##i(d,sl); }
|
||||
#define add(Ev,Gv) Ev(){ i=((a-=16)+C(r,4))/4,(\
|
||||
Gv?Ev() :0) ; } Ev##n(){ a=C(r,5),Ev(); }
|
||||
Tr(L,r, C(r,3)&&C(r,3)<=d?(l)(((int)B)+d+C(r,4)-C(r,3)):(((int)B)^d)>>24&&--\
|
||||
r,(l)d) Tr(Run,a,(ss=strcmp((F*)B+C((V(12)>>16),4)+C(--r,0),A(.strtab))?ss:(F\
|
||||
*)B+C(r ,4),C(r,1)-2),0) add(Sca ,V(-~i)-P+2) add(ru,strcmp(ss+V(i),A(main)))
|
||||
E(DX) { c *z? DX:DX <<030|(DX&65280)<<010|DX>>8&65280|DX>>24&0377; } l K(k){
|
||||
c L(E(k [(l)V(17)]),0); } V(v){ c E(B[v]); }
|
||||
|
||||
|
||||
main (char *ck, char **k) {
|
||||
exit(E((ck?main((z?(stat(M,&t)?P+=a+'{'?0:3:execv(M,k),a=G,i=P,y=G&255,sprintf(Q,y/'@'-3?A(*L(V(%d+%d)+%d,0)):A(R[%d]),(y&7),'\r',y/0100-1?0:G),(a+127&&a+'}'&&a+1?(a+61&&a+24&&a+025?(P=a+'H'&&a%061<=0?P:i,D(a>0?" R[%d]=E(~-E(R[%d])),\0 U R[%d],\0 R[%d] O,\0 U %d,\0R[%d]=0,"+(a&'8')*3:a <- 'c'?" %d, %c%s = R[%d], \0 %d, *R=%c%s==R[%d], \0 R[%d]=(int)%c%s,"-a%'w'%'j'*5:"%d,%d,%s=%d,",a>0?a-'h'?a-49?a&7:g:I:g,a>0?a&7:"& "[a%3%2+1],a+72?Q:A(*R),a>0|a<-99?g:I,0)):(P=i,i=a+61?a+21?E(I):G:0,D(a%' '+29+"P O,\0 U %d,P=%d,",P,P+i,0,0,0),p(d,"A'",b))):(n=g-4?g%5-1?a+127?G:I:0:(Scan(),*( x86?processor :d)=0,(int)(ss+V(i))),g%5<2?D(g%5?" %s=E(~-E(%s)), \0 U %s,"+4*g:"%s=E(E(%s)%c%d),",Q,Q,"+ - "[g],n,0):(a=G-'u'?'!':'=',D(g-4?"P=%d%c=%s?%d:%d,":"*R=E(((int(*)(l,l,l))%s)(K(1),K(2),K(3))),P O,",n,a,Q,P,P+G),p(d,"A'",b))))):(Run((z=(F*)&ck,stat(k[1],&t),B=(l)mmap(0,i=t.st_size,3,1,open(k[1],2),0))),magic((R[4]=E(B+i/4),run(),P=V(-~i),U 0)),sprintf(M,A(.%s%d),k[1],P),D("%s %s '-DX=A(%s)' -o %s '-Dmagic=",X,__FILE__,X,M,fflush(0)))),k):p(M,A(rm -f .%s*),M),*R)));
|
||||
}
|
||||
@@ -0,0 +1,136 @@
|
||||
Most likely to amaze:
|
||||
|
||||
The author wishes to remain anonymous
|
||||
Great Britain
|
||||
|
||||
|
||||
Judges' Comments:
|
||||
|
||||
To build:
|
||||
|
||||
make anonymous
|
||||
|
||||
Try:
|
||||
|
||||
./anonymous anonymous.ten
|
||||
|
||||
Is emulation the sincerest form of flattery? This small program does
|
||||
quite a lot of bit twiddling.
|
||||
|
||||
|
||||
Selected Author's Comments:
|
||||
|
||||
This program is an optimizing dynamic binary translator, allowing you to
|
||||
run x86 programs on any machine (x86 or otherwise).
|
||||
|
||||
I have included a simple "10 green bottles" program, already compiled
|
||||
for the x86. The program 'ten', and its source (dull) are given as info
|
||||
files. Warning: note that the translator screws around with the binary
|
||||
you run on it, *will* corrupt the binary to some extent, and may leave
|
||||
any program you run on it unusable.
|
||||
|
||||
The build script should give an example command to run.
|
||||
|
||||
Features
|
||||
|
||||
Basic Block Cache: Rather than translating each instruction individually
|
||||
the dynamic binary translator generates a translation for an entire
|
||||
basic block of subject code. Having translated a block once, the target
|
||||
code generated will be stored for the duration that the program is
|
||||
running, so as a program runs its performance will improve, as it hits
|
||||
cached blocks. This can be clearly observed in the example program,
|
||||
'ten'.
|
||||
|
||||
Target Library Linking:
|
||||
|
||||
The program runs dynamically linked elf binaries, and when the subject
|
||||
program attempts to make a call to a standard library, the translator
|
||||
attempts to make an appropriate call to the native system libraries on
|
||||
the target machine. This involves mangling between different calling
|
||||
conventions, etc.
|
||||
|
||||
Automatic Endian Detection/Reversal:
|
||||
|
||||
There are various problems raised when attempting to run little endian
|
||||
x86 code on a big endian chip, such as a PPC. These problems are dealt
|
||||
with in a manner that is entirely transparent to the user.
|
||||
|
||||
Configuration
|
||||
|
||||
Warnings:
|
||||
|
||||
By default the build script should compile the program with a set of
|
||||
switches such that while compiling the program it generates one error
|
||||
(which I feel is useful advice). The program should generate no further
|
||||
compiler errors while it is running (yes, the program can generate
|
||||
compiler errors while it is running). If you do not wish to see this
|
||||
error, or if the program generates any further error when compiled using
|
||||
your C compiler please remove the "warning=..." line from the build
|
||||
script.
|
||||
|
||||
Optimization:
|
||||
|
||||
The build script contains a "-O1" switch for the compiler. Increasing
|
||||
the optimization level will make the program run *slower*, while
|
||||
compiling the program without any optimization will allow it to run
|
||||
*faster*.
|
||||
|
||||
Obfuscation
|
||||
|
||||
The most obvious part of the obfuscation is probably the mess of defines
|
||||
at the top. This may seem a somewhat tired old obfuscation - however
|
||||
since many of these macros are (sometimes only) used by the program once
|
||||
it has dynamically recompiled itself, they are only referenced within
|
||||
the source code from within strings - and therefore the macros cannot be
|
||||
expanded. Furthermore, some of these strings of code are not given as
|
||||
strings, but instead are wrapped up in macros that use the "#"
|
||||
preprocessor operator to turn them into strings. In the hope throwing a
|
||||
few C beautifiers the macro to generate the strings is not contained
|
||||
within the source code but instead is passed in on the command line.
|
||||
|
||||
Buried under all this, and the fact that the entire program is just a
|
||||
call to exit, there are some nice subtle little obfuscations. For
|
||||
example, you may notice that there are a couple of macros that use the
|
||||
"##" preprocessor operator to build pairs of functions. One of these
|
||||
macros is used to build to pairs of functions of which only one has
|
||||
local variables which shadow global variables; so one modifies the
|
||||
global state, and the other doesn't.
|
||||
|
||||
There is also quite a nice trick where I wave a magic wand, and a chunk
|
||||
of code which should only be run when the program is run for the first
|
||||
time (setting the PC to point at main, etc) gets turned into a
|
||||
frog^M^M^M^Mstring. The C compiler sees a string by itself in the code,
|
||||
thinks "yup, thats a valid C expression", and quietly moves on to the
|
||||
next line of code.
|
||||
|
||||
Limitations
|
||||
|
||||
Due to space limitations only a handful of instructions are supported,
|
||||
those instructions which are supported may supported in somewhat
|
||||
non-conventional ways, chunks of the architecture (e.g. flags) are just
|
||||
ignored, the elf loader does not really load the elf binary, the target
|
||||
library linking can only pass up to 3 parameters to the target library
|
||||
function, etc, etc, etc.
|
||||
|
||||
In short, please consider this a full disclaimer for any bug that may
|
||||
turn up - yes the program is unsafe, but it's pretty cool anyway.
|
||||
|
||||
Despite all this, the translator is not exclusively limited to running
|
||||
the 'ten' program. Other trivial x86 programs may run on the translator
|
||||
- and I have successfully run a wide range of HelloWorld programs,
|
||||
including one of last years IOCCC winners, 'tomx'.
|
||||
|
||||
Complete Program
|
||||
|
||||
The fact that the program makes calls to system and execv may imply that
|
||||
it is not a complete program in its own right, as it relies on other
|
||||
programs. The call to system is a call to ask gcc to recompile the
|
||||
translator with a new set of switches, and the call to execv asks for
|
||||
the newly compiled program to be executed. I would point out that
|
||||
almost every other entry to this competition also require a C compiler
|
||||
(well, the published winners at any rate, and I recognize that a few
|
||||
don't). There is little real difference between this program and one
|
||||
like last years entry 'dhyang'; both are just C programs that generate C
|
||||
code as their output.
|
||||
|
||||
Enjoy, thanks!
|
||||
@@ -0,0 +1,19 @@
|
||||
#define PLURAL(bottles) bottles==1?"bottle":"bottles"
|
||||
|
||||
void sing(int bottles) {
|
||||
printf("%d green %s, standing on the wall.\n", bottles, PLURAL(bottles));
|
||||
}
|
||||
|
||||
int main() {
|
||||
int bottles = 10;
|
||||
|
||||
while(bottles) {
|
||||
sing(bottles);
|
||||
sing(bottles);
|
||||
printf("And if one green bottle should accidently fall,\nThere'd be ");
|
||||
sing(--bottles);
|
||||
printf("\n");
|
||||
}
|
||||
|
||||
return 0;
|
||||
}
|
||||
Reference in new issue
Block a user