Live data from Hacker News

An 8086 PC emulator in 4043 bytes

ioccc.org

11–20 of 39 posts

Re: An 8086 PC emulator in 4043 bytes

#11
post #6

Earlier quoted context omitted.

That's an old-school C function declaration. Note that the function return type are parameter types are implicitly int. nE is then explicitly declared to be a char pointer pointer.

But the char is outside of the declaration and before the opening brace - is this legal? And especially, why isn't it written like main(BX,char nE)? Doesn't save any bytes,it rather adds one semicolon...

Because it's not entirely about size, it's an obfuscation contest. Anything strange or unusual, especially something most people haven't seen used, will help obfuscate the code.

Re: An 8086 PC emulator in 4043 bytes

#12
post #6

Earlier quoted context omitted.

That's an old-school C function declaration. Note that the function return type are parameter types are implicitly int. nE is then explicitly declared to be a char pointer pointer.

But the char is outside of the declaration and before the opening brace - is this legal? And especially, why isn't it written like main(BX,char nE)? Doesn't save any bytes,it rather adds one semicolon...

Yes, it's very old fashioned (K&R era).

I think the reason for doing it this way rather than putting the type declaration alongside the parameter is then it would also demand also adding an int declaration for the BX parameter which would then cause the code to be longer. That is to say with:

    main(BX,char**nE){
.. it would throw an expected identifier error on the char. So you'd be putting the original:

    main(BX,nE)n**nE;{
Against this error-free alternative:

    main(int BX,n**nE){
.. but that's one byte longer.

If I got any of this wrong, I hope someone will correct me though :)

Re: An 8086 PC emulator in 4043 bytes

#13

Earlier quoted context omitted.

But the char is outside of the declaration and before the opening brace - is this legal? And especially, why isn't it written like main(BX,char nE)? Doesn't save any bytes,it rather adds one semicolon...

Yes, it's very old fashioned (K&R era). I think the reason for doing it this way rather than putting the type declaration alongside the parameter is then it would also demand also adding an int declaration for the BX parameter which would then cause the code to be longer. That is to say with: main(BX,char**nE){ .. it would throw an expected identifier error on the char. So you'd be putting the original: main(BX,nE)n*…

Sounds about right. The author mentions using K&R style function declarations as a way of shaving bytes in his writeup, too.

Re: An 8086 PC emulator in 4043 bytes

#15

Earlier quoted context omitted.

But the char is outside of the declaration and before the opening brace - is this legal? And especially, why isn't it written like main(BX,char nE)? Doesn't save any bytes,it rather adds one semicolon...

Yes, it's very old fashioned (K&R era). I think the reason for doing it this way rather than putting the type declaration alongside the parameter is then it would also demand also adding an int declaration for the BX parameter which would then cause the code to be longer. That is to say with: main(BX,char**nE){ .. it would throw an expected identifier error on the char. So you'd be putting the original: main(BX,nE)n*…

Ah, thanks for the explanation. Looks like the author did a deep, deep dive in the C language specs!

Re: An 8086 PC emulator in 4043 bytes

#16

This is interesting, though it might be a bit of a cheat. He's put some data in the BIOS image to assist in decoding instructions (not to take away from how amazing this is!): "CPU supports the full 8086/186 instruction set. Due to the complexities of the 8086’s arbitrary-length instruction decoding and flags, 8086 instructions are first converted to a simpler intermediate format before being executed. This conversio…

Abuse of the rules, if done well, is a time-honored IOCCC tradition.

Re: An 8086 PC emulator in 4043 bytes

#19

The source itself: http://ioccc.org/2013/cable3/cable3.c Or after running through preprocessing (not a huge help I found, sadly): https://gist.github.com/peterc/8259713

Strangely, visiting that Gist, GitHub asks me to log in. When I visit in a private browsing window, the Gist is displayed. Wasn't Google doing something like this, preventing registered users with an old cookie from seeing public content without signing in?
Post reply on HN