2
\$\begingroup\$

Since asking what I believe is the first Box-256 based question on Code Golf (Box-256 Assembly - BIG SQUARE II) there has been some confusion with regards to scoring.

I'd like this question to be a place where people can put forward scoring ideas so we can choose one that suites best Box256 challenges. I'd like to post up one code golf question for each of the built initial Box256 levels so we need a scoring systems that suites them.

\$\endgroup\$
1

5 Answers 5

Reset to default
4
\$\begingroup\$

Position of the last non-zero byte in the original program

Of course, trailing zeros can't be counted, otherwise all programs would be the same size. But empty lines within the program should be counted, because how wide the spacing between certain cells is is actually relevant information that needs to be encoded.

Hence, we simply count how many cells there are until the last non-zero cell, treating all four bytes in a nibble equally. Note that cells 2 to 4 in each nibble can contain * and @ modifiers beyond the byte their actually storing. However, Box-256 encodes this information into the first byte in addition to the OP code on that line, hence we don't need to count these separately. The - on the other hand is just syntactic sugar for 2's complement, i.e. -01 is completely equivalent to FF.

If we take the example solution for the first problem (and modify it slightly, which breaks it, but this is just an example):

MOV 022 @80 000
MOV 030 @C0 000
PIX @80 001 000
ADD @80 *C0 @80
ADD @81 001 @81
JGR 00B @81 -0C
MOV 000 @81 000
ADD @C0 001 @C0
JMP @08 000 000
000 000 000 000
000 000 000 000
000 000 000 000
-01 -10 000 000

That would be 50 bytes of code (up to the -10).

\$\endgroup\$
8
  • 1
    \$\begingroup\$ * and @ modifiers for bytes 1 to 3 on a line of code are all stored in byte 0 of the same line (which also stores the opcode) so there's no need to account for them separately. \$\endgroup\$
    – impomatic
    Apr 24, 2016 at 6:26
  • \$\begingroup\$ @impomatic Ohh, I didn't notice that, I'll update the answer. \$\endgroup\$
    – Martin Ender
    Apr 24, 2016 at 9:58
  • 1
    \$\begingroup\$ -1 from me, even just because it disallows this solution for the checkerboard. \$\endgroup\$
    – orlp
    Apr 24, 2016 at 14:22
  • 1
    \$\begingroup\$ @orlp I don't understand why the zeros in that shouldn't be counted. This is no different from significant whitespace in a Befunge program. \$\endgroup\$
    – Martin Ender
    Apr 24, 2016 at 14:24
  • 3
    \$\begingroup\$ @MartinBüttner I'm envisioning the all-zero BOX-256 machine as a 'clean slate', where a programmer replaces bytes of his choice by other values, costing one unit per byte. Any byte that is left unchanged does not cost anything. Consider a fixed-size Hexagony challenge - you wouldn't count the size of the board in that either. In the end what matters is whether the fixed size nature of the BOX-256 is fundamental, and since everything about it is 8-bit, I'd argue that its size is fundamental, and not a 'cost' of the program. \$\endgroup\$
    – orlp
    Apr 24, 2016 at 14:30
  • \$\begingroup\$ I think this is the best answer. If you think about how REDCODE is written, this is similar. For the purpose of placing the program in memory, the empty lines/bytes are required and should included in the score. \$\endgroup\$
    – mbomb007
    Apr 27, 2016 at 14:33
  • \$\begingroup\$ @orlp I understand what you are staying, if you want to get really literal then imaging turning a computer on, all memory is blank to start with so we can’t count that as intended lines of code. However I agree with Martin Büttner. In the example answer you linked to for the checkerboard solution, those aren't just empty memory spaces they are NOPs. The NOP instruction in BOX-256 is opcode 0. And the "white-space" provide by all those zero's is actually an integral part of that code being able to provide a valid answer, it’s a NOP sled. \$\endgroup\$
    – jwbensley
    Apr 28, 2016 at 12:47
  • \$\begingroup\$ ...In the case the NOPs aren’t actually required one can move the code up from the bottom and it would be 4 lines of code but those NOPs are required for this answer to work. \$\endgroup\$
    – jwbensley
    Apr 28, 2016 at 12:47
1
\$\begingroup\$

Lines of Code as counted by BOX-256

BOX-256 automatically counts the lines of code. Why not score by the built in count? Lines containing instructions or non-zero data are counted.

For example the following counts as 2 lines of code:

    PIX @0C @0D
    000 000 000 000
    000 000 000 000
    088 008 000 000

It's important to include data lines in the count otherwise the optimal solution to every BOX-256 problem is same tiny loop with different data.

\$\endgroup\$
1
  • 2
    \$\begingroup\$ I'm not sure that not counting empty internal lines is a good idea. If those really aren't needed, then you can always move your data or code lines further up to close the gap. If they are needed they're important information that is encoded in the source and should be counted. \$\endgroup\$
    – Martin Ender
    Apr 24, 2016 at 10:02
-1
\$\begingroup\$

Number of characters/bytes in the program

MOV A B C is 9 bytes.

MOV A B C
PIX A B

is 17 bytes.

This is fairly normal for most languages.

\$\endgroup\$
2
  • 1
    \$\begingroup\$ -1 from me, the BOX-256 assembly language is just a programmer-friendly frontend for the actual code (shown directly to the right of the source). As an example, -FF is exactly the same as 01, and this just makes golfing more annoying. And THR 00 is the same 7E00. \$\endgroup\$
    – orlp
    Apr 24, 2016 at 14:36
  • \$\begingroup\$ I agree with @orlp that these are just being turned into Opcodes so counting the bytes of the letters that make up the instruction name is not good. You can put the opcodes in directly so we can reduce the byte count for all programs in that way. \$\endgroup\$
    – jwbensley
    Apr 28, 2016 at 12:34
-1
\$\begingroup\$

Number of non-zero bytes in the initial state.

We ignore the assembly instructions, and only look at the state. We count the number of non-zero bytes in this initial state.

In the example below, there are 15 non-zero bytes.

illustration of initial state

\$\endgroup\$
3
  • \$\begingroup\$ We count spaces in 2D languages and other forms of non-removable NO-OPs as well. I don't see why it should be different here. \$\endgroup\$
    – Martin Ender
    Apr 24, 2016 at 14:29
  • \$\begingroup\$ @MartinBüttner Because in my opinion the fixed size of the BOX-256 is fundamental to its nature, and it does not become smaller if the user doesn't use its full space. \$\endgroup\$
    – orlp
    Apr 24, 2016 at 14:32
  • 1
    \$\begingroup\$ +1, if we're not going to use BOX-256's built in LOC this is the next best option. It still allows arbitrary code spacing and also takes away the advantage of misaligned code. However, minimizing non-zero bytes would mostly come down to making the best use of location 00, e.g.: ADD 001 @ 11 @11 MUL 088 @ 11 *00 DIV *00 080 *00 ADD 002 *00 *00 PIX 000 *00 000 \$\endgroup\$
    – impomatic
    Apr 28, 2016 at 8:35
-2
\$\begingroup\$

Number of bytes in the instructions and arguments

The length of the program, minus spaces and padding.

MOV A B C is 6 bytes.

MOV A B C
PIX A B

is 12 or 11 bytes, depending if you count the newline.

\$\endgroup\$
3
  • \$\begingroup\$ I don't know why people hate this answer much more than the whitespace-including version. \$\endgroup\$
    – CalculatorFeline
    Apr 27, 2016 at 16:23
  • \$\begingroup\$ @CatsAreFluffy yeah. \$\endgroup\$
    – Riker
    Apr 27, 2016 at 16:34
  • \$\begingroup\$ You haven't said what to do about "white-space", refering to the answer @orlp has posted, how many bytes is that in your method? bare in mind that all the "white-space" of 0's in the middle is actually executed NOPs. \$\endgroup\$
    – jwbensley
    Apr 28, 2016 at 12:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .