⚡ Feature: Emit-C #50

New Issue

deavmi · 2022-12-15T16:09:23Z

deavmi commented

2022-12-15 16:09:23 +00:00

Behaviour-C

This is a living document describing what needs to be taken care of in terms of the generated C code and what implied aspects of C's behaviour are to be taken note of explicitly.

Function calls

C has underspecified behaviour when it comes to function call argument evaluation ordering. In fact it is known, through my own research project I conducted that the following C code will give differing results between gcc and clang:

int counter = 0;

int count()
{
	counter = counter + 1;
	return counter;
}

int func(int x1, int x2)
{
	return x1*2+x2;
}

int main()
{
	int value = func(count(), count());

	return 0;
}

This produces 5 in gcc (right-to-left) and 4 in clang (left-to-right).

We should analyse dgen.c's function call emit code and preinline the arguments to ensure we don't have underspecified behaviour (enforcing left-to-right)!

Todo

Preinliner functionality
- Rolling counter
- Emit build up
  - Basic
  - Nice gen tabs
- Determine when to emit this, it must be before the outermost function call

## Behaviour-C This is a living document describing what needs to be taken care of in terms of the generated C code and what implied aspects of C's behaviour are to be taken note of **explicitly**. ### Function calls C has underspecified behaviour when it comes to function call argument evaluation ordering. In fact it is known, through my [own research project I conducted](http://deavmi.assigned.network/research/) that the following C code will give differing results between `gcc` and `clang`: ```c int counter = 0; int count() { counter = counter + 1; return counter; } int func(int x1, int x2) { return x1*2+x2; } int main() { int value = func(count(), count()); return 0; } ``` This produces `5` in `gcc` (right-to-left) and `4` in `clang` (left-to-right). We should analyse dgen.c's function call emit code and preinline the arguments to ensure we don't have underspecified behaviour (**enforcing left-to-right**)! --- ## Todo - [ ] Preinliner functionality - [x] Rolling counter - [x] Emit build up - [x] Basic - [ ] Nice gen tabs - [x] Determine **when** to emit this, it must be before the outermost function call

deavmi self-assigned this 2022-12-15 16:09:23 +00:00

deavmi added this to the Code emit project 2022-12-15 16:09:24 +00:00

deavmi added the

emit

label 2022-12-15 16:10:29 +00:00

deavmi added this to the Basics milestone 2023-01-13 08:40:06 +00:00

deavmi removed this from the Basics milestone 2023-01-13 08:40:11 +00:00

deavmi changed reference from ~~vardec_varass_dependency~~ to feature/behavec_preinline

2023-08-16 15:43:13 +01:00

deavmi added this to the Basics milestone 2023-08-16 15:43:16 +01:00

deavmi added spent time 2023-08-16 15:43:22 +01:00

30 minutes

deavmi started working 2023-08-16 15:43:25 +01:00

deavmi added the due date 2023-08-17

2023-08-16 15:43:36 +01:00

deavmi changed title from ~~Emit-C~~ to ⚡ Feature: Emit-C

2023-08-16 15:44:11 +01:00

deavmi stopped working 2023-08-16 15:55:35 +01:00

12 minutes 10 seconds

deavmi added spent time 2023-08-16 19:05:50 +01:00

10 minutes

deavmi started working 2023-08-19 14:17:44 +01:00

deavmi commented

2023-08-19 14:22:25 +01:00

Behaviour-C

This is a living document describing what needs to be taken care of in terms of the generated C code and what implied aspects of C's behaviour are to be taken note of explicitly.

Function calls

C has underspecified behaviour when it comes to function call argument evaluation ordering. In fact it is known, through my own research project I conducted that the following C code will give differing results between gcc and clang:
int counter = 0;

int count()
{
	counter = counter + 1;
	return counter;
}

int func(int x1, int x2)
{
	return x1*2+x2;
}

int main()
{
	int value = func(count(), count());

	return 0;
}
This produces 5 in gcc (right-to-left) and 4 in clang (left-to-right).

We should analyse dgen.c's function call emit code and preinline the arguments to ensure we don't have underspecified behaviour (enforcing left-to-right)!

Todo

Preinliner functionality

Rolling counter

Emit build up

Basic

Nice gen tabs

Determine when to emit this, it must be before the outermost function call

Working on tabbing the generated code out nicely now...

> ## Behaviour-C > > This is a living document describing what needs to be taken care of in terms of the generated C code and what implied aspects of C's behaviour are to be taken note of **explicitly**. > > > ### Function calls > > C has underspecified behaviour when it comes to function call argument evaluation ordering. In fact it is known, through my [own research project I conducted](http://deavmi.assigned.network/research/) that the following C code will give differing results between `gcc` and `clang`: > > ```c > int counter = 0; > > int count() > { > counter = counter + 1; > return counter; > } > > int func(int x1, int x2) > { > return x1*2+x2; > } > > int main() > { > int value = func(count(), count()); > > return 0; > } > ``` > > This produces `5` in `gcc` (right-to-left) and `4` in `clang` (left-to-right). > > We should analyse dgen.c's function call emit code and preinline the arguments to ensure we don't have underspecified behaviour (**enforcing left-to-right**)! > > --- > > ## Todo > > - [ ] Preinliner functionality > - [x] Rolling counter > - [x] Emit build up > - [x] Basic > - [ ] Nice gen tabs > - [x] Determine **when** to emit this, it must be before the outermost function call Working on tabbing the generated code out nicely now...

deavmi commented

2023-08-19 14:30:44 +01:00

Behaviour-C

This is a living document describing what needs to be taken care of in terms of the generated C code and what implied aspects of C's behaviour are to be taken note of explicitly.

Function calls

C has underspecified behaviour when it comes to function call argument evaluation ordering. In fact it is known, through my own research project I conducted that the following C code will give differing results between gcc and clang:
int counter = 0;

int count()
{
	counter = counter + 1;
	return counter;
}

int func(int x1, int x2)
{
	return x1*2+x2;
}

int main()
{
	int value = func(count(), count());

	return 0;
}
This produces 5 in gcc (right-to-left) and 4 in clang (left-to-right).

We should analyse dgen.c's function call emit code and preinline the arguments to ensure we don't have underspecified behaviour (enforcing left-to-right)!

Todo

Preinliner functionality

Rolling counter

Emit build up

Basic

Nice gen tabs

Determine when to emit this, it must be before the outermost function call
Working on tabbing the generated code out nicely now...

I have something working but it still looks a little bit. Here is the output code (it does look better though):

int32_t banana(int32_t t_dfb9f9d287f84736e7c04608e8443a70)
{
	int32_t t_280ac0fbb9196fef914d76c791b222ff = 64;
		int32_t preinliner_0_5 = 1;
	int32_t preinliner_1_6 = 2;
	int32_t preinliner_2_6 = 3;
	int32_t preinliner_3_5 = apple(preinliner_1_6, preinliner_2_6);

t_7b6d477c5859059f16bc9da72fc8cc3b = 1+t_280ac0fbb9196fef914d76c791b222ff+apple(preinliner_0_5, preinliner_3_5)+t_7b6d477c5859059f16bc9da72fc8cc3b;
	return 0;
}

For reference the input TLang code was:

module simple_functions;

int j = 21;
int k = 22;

int apple(int arg1, int arg2)
{
    int h = 69;

    arg1=1+arg1;

    k=arg1+arg2;
    simple_functions.k=arg1+arg2;

    return arg1;
}

int banana(int arg1)
{
    int h = 64;

    k=1+h+apple(1, apple(2, 3))+k;
    
    return 0;
}

> > ## Behaviour-C > > > > This is a living document describing what needs to be taken care of in terms of the generated C code and what implied aspects of C's behaviour are to be taken note of **explicitly**. > > > > > > ### Function calls > > > > C has underspecified behaviour when it comes to function call argument evaluation ordering. In fact it is known, through my [own research project I conducted](http://deavmi.assigned.network/research/) that the following C code will give differing results between `gcc` and `clang`: > > > > ```c > > int counter = 0; > > > > int count() > > { > > counter = counter + 1; > > return counter; > > } > > > > int func(int x1, int x2) > > { > > return x1*2+x2; > > } > > > > int main() > > { > > int value = func(count(), count()); > > > > return 0; > > } > > ``` > > > > This produces `5` in `gcc` (right-to-left) and `4` in `clang` (left-to-right). > > > > We should analyse dgen.c's function call emit code and preinline the arguments to ensure we don't have underspecified behaviour (**enforcing left-to-right**)! > > > > --- > > > > ## Todo > > > > - [ ] Preinliner functionality > > - [x] Rolling counter > > - [x] Emit build up > > - [x] Basic > > - [ ] Nice gen tabs > > - [x] Determine **when** to emit this, it must be before the outermost function call > > Working on tabbing the generated code out nicely now... I have something working but it still looks a little bit. Here is the output code (it does look _better_ though): ```c int32_t banana(int32_t t_dfb9f9d287f84736e7c04608e8443a70) { int32_t t_280ac0fbb9196fef914d76c791b222ff = 64; int32_t preinliner_0_5 = 1; int32_t preinliner_1_6 = 2; int32_t preinliner_2_6 = 3; int32_t preinliner_3_5 = apple(preinliner_1_6, preinliner_2_6); t_7b6d477c5859059f16bc9da72fc8cc3b = 1+t_280ac0fbb9196fef914d76c791b222ff+apple(preinliner_0_5, preinliner_3_5)+t_7b6d477c5859059f16bc9da72fc8cc3b; return 0; } ``` For reference the input TLang code was: ```d module simple_functions; int j = 21; int k = 22; int apple(int arg1, int arg2) { int h = 69; arg1=1+arg1; k=arg1+arg2; simple_functions.k=arg1+arg2; return arg1; } int banana(int arg1) { int h = 64; k=1+h+apple(1, apple(2, 3))+k; return 0; } ```

deavmi modified the due date from 2023-08-17 to 2023-08-23

2023-08-19 14:47:41 +01:00

deavmi commented

2023-08-19 14:58:38 +01:00

Behaviour-C

This is a living document describing what needs to be taken care of in terms of the generated C code and what implied aspects of C's behaviour are to be taken note of explicitly.

Function calls

C has underspecified behaviour when it comes to function call argument evaluation ordering. In fact it is known, through my own research project I conducted that the following C code will give differing results between gcc and clang:
int counter = 0;

int count()
{
	counter = counter + 1;
	return counter;
}

int func(int x1, int x2)
{
	return x1*2+x2;
}

int main()
{
	int value = func(count(), count());

	return 0;
}
This produces 5 in gcc (right-to-left) and 4 in clang (left-to-right).

We should analyse dgen.c's function call emit code and preinline the arguments to ensure we don't have underspecified behaviour (enforcing left-to-right)!

Todo

Preinliner functionality

Rolling counter

Emit build up

Basic

Nice gen tabs

Determine when to emit this, it must be before the outermost function call
Working on tabbing the generated code out nicely now...
I have something working but it still looks a little bit. Here is the output code (it does look better though):
int32_t banana(int32_t t_dfb9f9d287f84736e7c04608e8443a70)
{
	int32_t t_280ac0fbb9196fef914d76c791b222ff = 64;
		int32_t preinliner_0_5 = 1;
	int32_t preinliner_1_6 = 2;
	int32_t preinliner_2_6 = 3;
	int32_t preinliner_3_5 = apple(preinliner_1_6, preinliner_2_6);

t_7b6d477c5859059f16bc9da72fc8cc3b = 1+t_280ac0fbb9196fef914d76c791b222ff+apple(preinliner_0_5, preinliner_3_5)+t_7b6d477c5859059f16bc9da72fc8cc3b;
	return 0;
}
For reference the input TLang code was:
module simple_functions;

int j = 21;
int k = 22;

int apple(int arg1, int arg2)
{
    int h = 69;

    arg1=1+arg1;

    k=arg1+arg2;
    simple_functions.k=arg1+arg2;

    return arg1;
}

int banana(int arg1)
{
    int h = 64;

    k=1+h+apple(1, apple(2, 3))+k;
    
    return 0;
}

I know exactly what it is. The emitFUnctionDefinition(string) will tab each emitted instruction but these are not Instructions but strings, so what would have been padded is now wrongly padded. I will look into the cleanest way to solve this soon.

> > > ## Behaviour-C > > > > > > This is a living document describing what needs to be taken care of in terms of the generated C code and what implied aspects of C's behaviour are to be taken note of **explicitly**. > > > > > > > > > ### Function calls > > > > > > C has underspecified behaviour when it comes to function call argument evaluation ordering. In fact it is known, through my [own research project I conducted](http://deavmi.assigned.network/research/) that the following C code will give differing results between `gcc` and `clang`: > > > > > > ```c > > > int counter = 0; > > > > > > int count() > > > { > > > counter = counter + 1; > > > return counter; > > > } > > > > > > int func(int x1, int x2) > > > { > > > return x1*2+x2; > > > } > > > > > > int main() > > > { > > > int value = func(count(), count()); > > > > > > return 0; > > > } > > > ``` > > > > > > This produces `5` in `gcc` (right-to-left) and `4` in `clang` (left-to-right). > > > > > > We should analyse dgen.c's function call emit code and preinline the arguments to ensure we don't have underspecified behaviour (**enforcing left-to-right**)! > > > > > > --- > > > > > > ## Todo > > > > > > - [ ] Preinliner functionality > > > - [x] Rolling counter > > > - [x] Emit build up > > > - [x] Basic > > > - [ ] Nice gen tabs > > > - [x] Determine **when** to emit this, it must be before the outermost function call > > > > Working on tabbing the generated code out nicely now... > > I have something working but it still looks a little bit. Here is the output code (it does look _better_ though): > > ```c > int32_t banana(int32_t t_dfb9f9d287f84736e7c04608e8443a70) > { > int32_t t_280ac0fbb9196fef914d76c791b222ff = 64; > int32_t preinliner_0_5 = 1; > int32_t preinliner_1_6 = 2; > int32_t preinliner_2_6 = 3; > int32_t preinliner_3_5 = apple(preinliner_1_6, preinliner_2_6); > > t_7b6d477c5859059f16bc9da72fc8cc3b = 1+t_280ac0fbb9196fef914d76c791b222ff+apple(preinliner_0_5, preinliner_3_5)+t_7b6d477c5859059f16bc9da72fc8cc3b; > return 0; > } > ``` > > For reference the input TLang code was: > > ```d > module simple_functions; > > int j = 21; > int k = 22; > > int apple(int arg1, int arg2) > { > int h = 69; > > arg1=1+arg1; > > k=arg1+arg2; > simple_functions.k=arg1+arg2; > > return arg1; > } > > int banana(int arg1) > { > int h = 64; > > k=1+h+apple(1, apple(2, 3))+k; > > return 0; > } > ``` I know exactly what it is. The `emitFUnctionDefinition(string)` will tab each emitted instruction but these are not `Instruction`s but strings, so what would have been padded is now wrongly padded. I will look into the cleanest way to solve this soon.

deavmi stopped working 2023-08-19 14:58:44 +01:00

41 minutes

deavmi started working 2023-08-27 12:05:08 +01:00

deavmi commented

2023-08-27 12:07:15 +01:00

Updated with latest code from vardec_varass_dependency. The code coverage should be higher now. 👍

Updated with latest code from `vardec_varass_dependency`. The code coverage should be higher now. 👍

deavmi stopped working 2023-08-27 12:07:19 +01:00

2 minutes 12 seconds

deavmi modified the due date from 2023-08-23 to 2023-08-31

2023-08-27 12:07:43 +01:00

deavmi modified the due date from 2023-08-31 to 2023-11-06

2023-11-06 09:36:32 +00:00

deavmi modified the due date from 2023-11-06 to 2023-11-20

2023-11-06 09:36:53 +00:00

deavmi commented

2023-11-06 09:37:49 +00:00

This should be finished prior to #157 as I want to get these changes in and upstream them into that issue's branch, rather than deal with many merge conflicts later.

Sign in to join this conversation.

No Label