Great, but needs some things.

[chorman0773]

If I can request, it would be good if the Compiler was designed with all major features. One thing is that the primitive types in C include all, including a 64 bit long. It could be setup to operate on 2 ints at once. Also The c standard library should be provided, the other integral types could be setup to do something similar to java, where char, and short are promoted to int, with unsigned values being 0-extended, and signed values being sign-extended. (IE. FFFF would be FFFFFFFF if it starts as a (signed) short but 0000FFFF if it starts as an unsigned short.) Also if possible pointers and indirection would be greatly appreciated. (Like MOV 1, [] -> in most assembly languages, when a memory address is given, but is enclosed in [], it refers to using the memory address stored within .
I know that function-pointers are probably not possible, but all other parts of C should be possible to implement. The last thing is indexing (in ASM). It should be possible to index a memory address from a given.
Finally, this should probably be updated to Minecraft 1.13 command-set, because 1.12 commands are incompatible with 1.13, and 1.13 will be more versitile.
All in all, this is an amazing thing, and assuming that I can utilize the standard library and all of the internals, It would because possible to implement the VM of a High-Level Language, and total control MC.

[simon816]

It's possible to add different sized integer types, but note that it would add some overhead to arithmetic operations. Integers >32 bits would be even more complex (but possible).
I agree this would be a nice feature to have. using int will always yield best performance though.

The c standard library should be provided

maybe portions could be, but this is not something I think will be possible (at least with reasonable performance). Someone other than me could attempt this if they wish.
Note that floating points are not natively supported in scoreboards, so a floating point implementation will have to be written (not exactly very performant).

Also if possible pointers and indirection would be greatly appreciated

Already possible :) Dereferencing structs etc work as expected. This behaviour is an extension to the assembly language only possible using C. (See these instruction in asm_extensions.py)

I know that function-pointers are probably not possible

They actually are possible, with the use of a function lookup table. The compiler doesn't currently support it but a table is generated when using SYNC (see add_lookup_table). Each function is given a unique number and the table just does a load of if-elseif-elseif to find the corresponding function.

The last thing is indexing (in ASM). It should be possible to index a memory address from a given.

Looks like you didn't finish the sentence. I assume you're talking about an offset index from a base address (like MOV [esp+0x04], eax in x86). This is possible with the new instructions in asm_extensions.py and the compiler makes use of this.
I would add it to the assembly language, except it requires the use of a memory region. There is no actual addressable memory with the assembler, which I mentioned in the readme. With the C compiler, it defines a continuous memory region using scoreboard objectives (i.e. mem_0, mem_1, mem_2) and adds a lookup table to find the correct slot (using a binary search).
This is something I wanted to avoid in the assembler, but was required for the compiler. (The stack PUSH/POP actually already do this, but for a relatively small stack size, so use this if you need this with the assembly language).

Finally, this should probably be updated to Minecraft 1.13 command-set, because 1.12 commands are incompatible with 1.13, and 1.13 will be more versitile.

Yep, will be updated. Probably will wait for it to stabilise first.

It would because possible to implement the VM of a High-Level Language

theoretically :p
Even a simple tetris game has a large amount of overhead, and runs really slowly (and that's even without time-sharing with the rest of the Minecraft's tick cycle)

[chorman0773]

Adding all the fundamental types would make 2 things better:
1 -> It would complete the c standard
2 -> It would make it easier to use pointers,

Also, it allows for more descriptive uses types. Yes have type promotion would have some overhead, but it would make programs more readable.

One potential change, would be to use NBT tags with /data and /execute store, over objectives. It would make indirection easier (assuming that we get variables in functions).
Also just curious how string literals are stored, since char is not a type in your compiler, and also curious if your compiler supports Variadic functions?

[simon816]

One potential change, would be to use NBT tags with /data and /execute store, over objectives.

I wanted to use NBT, but I have not been able to find a way to transfer data to/from scoreboards. Scoreboards are required to perform the actual arithmetic on values.

Also just curious how string literals are stored, since char is not a type in your compiler.

Currently there is not a real string type. Strings are injected directly into the commands and are not treated as data (which is why you can't perform any string operations).

[chorman0773]

As for transferring data, I know that in 1.13 it is possible to convert nbt into scoreboards with /execute store score run data get
As for strings, I would store it as a pointer to a memory address, which has n characters, and ceil(n/4) bytes. You could stored char*'s as pointers to multiple characters, which will keep reintrepretation state correct (IE, if a char* consists of 4 chars, an int* consists of 1 int which is stored that way). I would recommend using big-endian, as that will keep it consistant with other things. Also an Idea I had, stems from this, that you store multiple <4 byte data-types in a single scoreboard objective>. Though even with NBT you would still have to do operations in integers, you would have to implement special floating-point operations.

[chorman0773]

BTW I have to ask how TEST works in c code with the asm tag, and what instructions allow for dereferencing, in the extended ASM that C uses?

[simon816]

As for transferring data, I know that in 1.13 it is possible to convert nbt into scoreboards with /execute store score run data get

I've taken a quick look at this, it's almost possible make use of /execute but I don't see a way to dynamically specify the path, which means there isn't any advantage over a scoreboard objective.

Storing multiple values in a single objective is possible with bitwise operations, but they are much less efficient than a typical CPU. It has to loop over each bit (so 32 iterations) for every operation, which gets expensive. (this is what it generates)

BTW I have to ask how TEST works in c code with the asm tag

There is a built in function, __test_command which returns 1 if the command succeeds or 0 if it fails.

what instructions allow for dereferencing, in the extended ASM that C uses?

I linked to them earlier
They are:

• MOVIND (MOV [src+s_off], [dest+d_off])
• MOVINDD (MOV src, [dest+d_off])
• MOVINDS (MOV [src+s_off], dest)

[chorman0773]

So the use of NBT would enable you to store data in a Byte-Array. The advantage to using it is space. While a single byte in java takes a full int (as java does not store byte, short, or char types in VM code), a Byte array, takes 1/4 of the size of the same length int [] (assuming that the array length is in multiples of 4. Plus, using alot of scoreboard objectives would be extremely problemattic as it makes it hard for people running it to decipher objectives. The use of a few objectives, say the SP, the current handle function number, and a few registers for operations places a slight overhead (for transfer and decoding), but all in all an advantage for high-level programs (which use a massive ammount of data). It would also serve to enable dynamic allocation with functions like malloc and calloc. (You would also have to store information about allocation, but that can also use a byte[].)
If you do add this, the way I have pseudo-implemented the allocations, is to flag memory map with flags. I would keep the flags the same. The flags I use are M_read (0x01), and M_write (0x02).
Also using byte[]'s would allow you to store unaligned 4-bytes, and also store other values.

For 8-byte values, I would keep the same manipulation registers (Say X and Y), but also add LX_H and LY_H. These registers represent the high-byte of the 8-byte value, and cannot be used directly.
Adding processor flags would allow you to "enable"-disable standard manipulation of the X and Y registers. I would also do this for your acc register.
It would add a few instructions for 8-byte usage, but other than that, would work the same way.

Another question is how function symbols are stored, and what the function mapping is for the call lookup table (which the stack uses)? Also to ask, is there an option to output the symbol table with compilation into a file? (So that I can call a C function from an advancement)
I know that the basic answer is (probably) within the code, but I don't use python, and don't really understand it. My primary Background is in Java, then Lua, followed by C and C++.

[simon816]

I will take a look at using byte arrays when I next work on CBA.

Not sure that providing low/hi parts of a register has any advantage here, other than more flexible register manipulation. Unlike real hardware where this doesn't have additional overhead, in the context of scoreboards it'll be less performant.

Another question is how function symbols are stored, and what the function mapping is for the call lookup table (which the stack uses)?

Each function is given a numerical ID, which is a CRC32 of the function name, see here.
The func_lookup_table function is generated as a if-elseif-else block on all the function IDs.

Also to ask, is there an option to output the symbol table with compilation into a file?

Good idea, there's no specific way to do that, I will add that as an option.
You can figure out the function name if you know the namespace given.
It will be: {namespace}:sub_{function_name}
e.g. in the tetris example, using --namespace c_generated, the new_shape function is called c_generated:sub_new_shape

[chorman0773]

Took a look at your new API.
I already pointed this out in a related question, but from examining the python code (have a bit more experience now then I did previously), it looks like many of the things require literal expressions. While this is fine, it may be prudent to extend it to constant expressions. For example: the following code would be valid (if I understand the python correctly this doesn't work currently)

const char myMSG[]="Hello World";
printf(myMSG); //Would like to use puts here but you cant have it all

There are other use cases, where the feature makes sense, such as having the same basic format string being used in multiple places. There could also be a __format intrinsic which gives you back a constant string based on format arguments.

[chorman0773]

Question: are bitfields supported? As in
struct S{
unsigned A:16;
unsigned B:8;
unsigned C:7;
_Bool D:1;
};
If so, I can use my qc hack:
typedef union __qc_float32{
unsigned bits:32; //Yes this is required, __qc_float32 basically is a float and aliasing rules apply here. Thankfully you can't take the address of a bitfield or bind a bitfield to a reference in C++.
float val;
struct{
unsigned sign:1;
unsigned exp:8;
unsigned sig:23;
} rep;
} __qcfloat;
Also can you extend bitfields in C to allow (un)signed long long when they get added? So I can set up double the same way.

[simon816]

Bitfields are not currently supported. I figured it'd not be a widely used feature. Bitwise operations are expensive compared to arithmetic, due to all values in a scoreboard are ints, you'd need to divide or multiply by 2 in a loop to get to the desired bit. It should still be possible to do this with << and >>.

If I was to add decimal values, I'd probably go for a fixed point instead. e.g. scale everything by 1000 so it can be kept as integer arithmetic.

[chorman0773]

qc is a decent library. It also happens to have optimizations that are specific to floating point numbers.
And yeah, most bitfields would be stupid w/o bitwise operations in scoreboards (that will probably go into my next proposal). Though yeah, I do have a bitfield there to protect from taking the address, and violating aliasing rules (even though qc basically violates every type-punning rule in the book but hey, its a library designed to be used with a compiler or backend support (the original use was a SoftFP library for a Snes Homebrew llvm backend). Also just a question, but have you considered an llvm backend for CBA, then having the C support of clang?

[simon816]

have you considered an llvm backend for CBA, then having the C support of clang?

Someone else suggested that too:
https://www.reddit.com/r/Minecraft/comments/7fnzv4/i_wrote_a_c_compiler_that_creates_minecraft/dqd9osn/

The thing I'm having most difficulty with at the moment is optimisations and a good IR, so LLVM would definitely be useful for that.
I may try out creating an LLVM backend if I don't get much further with the current implementation.