[MSX-C] Q&A official thread | MSX Resource Center (Page 25/57)

Prophet (3105)

23-09-2015, 22:07

Hi people, here goes again. I have a trouble with -rP:S:H compiler option.

Question: How it works -r option? I know that it's ratio between Pool:Symbol table:Hash but has strange effects. I have a source code that uses too few Symbol table:

So I have decided to change default compiler options (13:6:4) for a more balanced configurarion (13:5:5) and I get this:

Why symbol table grows too much? I only changed from 13:6:4 to 13:5:5 :(

By anonymous

incognito ergo sum (116)

23-09-2015, 22:34

AxelStone wrote:

Question: How it works -r option? I know that it's ratio between Pool:Symbol table:Hash but has strange effects. I have a source code that uses too few Symbol table:

The way it works is very simple: the parser has a certain amount of work memory to work with. This command line option defines how to assign this memory. The numbers you see after CG runs refer only to CG, not to the compiled program.

The symbol table grows and shrinks during the parsing process. The numbers you see after the process is complete is just the final sizes of these tables. A small symbol table after CG runs is not a problem. It just means that there area few global symbols (variables, functions, etc). During the parsing process the symbol table grows and shrinks depending on how many variables or functions the program is handling. A function that uses lots of internal variables will use a bigger symbol table while the program processes that function.

As long as the program compiles you don't need to worry about the -r parameters. Probably you have a function that uses lots of variables, and the smaller symbol table wasn't big enough to hold all the temporary symbols.

By AxelStone

Prophet (3105)

23-09-2015, 23:08

Ok so the best option is not to modify -r. I remember the post writen by Silvestre a few days ago talking precisely about memory troubles and the solution is simply split into several sources. It seems that I'm near to reach the same point.

Thanks

By anonymous

incognito ergo sum (116)

23-09-2015, 23:35

Yes, it seems that you have a decently sized program already. :-)

By AxelStone

Prophet (3105)

24-09-2015, 23:19

JaviLM wrote:

Yes, it seems that you have a decently sized program already. :-)

Still not enought, I'm working on it ittle by little . This time, I'm going to make a suggestion instead a question . I've discovered that MSX-C supports the way of declaring extern variables of ANSI-C, that it's really the best way (if you are bored, you can read this.

Basically you can split between declaration and definition of variable, so .h files and .c files does they are supposed to do and your code is more legible. Here goes how you should declare extern variables:

FILE1.H

#include<stdio.h>
extern int globalVar; /* Declaration of variable made in header file */

initVar();

FILE1.C

#include<stdio.h>
#include"file1.h"
int globalVar; /* Definition checked against declaration */

initVar() {
     globalVar=5;
}

Once the var has been defined, the compiler has reserved its space.

FILE2.C

#include<stdio.h>
#include"file1.h"

main(){
    initVar();
    printf("%d",globalVar);
}

By this way, all global vars are located in your header files and you only has to define in the file that is going to use it.

By Sylvester

Hero (554)

25-09-2015, 22:06

An other question, I would like to read the stdin as the more MSX-DOS command so I can do:
a:> dir *.c | test
and then print the list as a string. I now have the following, but it's printing garbage again

#include <stdio.h>
#define BUF_SIZE 1024

main()
{
  char c;
  char *content = alloc(sizeof(char) * BUF_SIZE);

  if (content == NULL) {
    printf("Failed to allocate content");
    exit(1);
  }

  content[0] = '\0';
  while((c = getchar()) != EOF) {
    if (strlen(content) < BUF_SIZE){
       strcat(content, c);
       content[strlen(content)-1] = '\0';
    }
  }

  printf("String:\n\n%s\n", content);
  free(content);
}

By bore

Master (138)

25-09-2015, 23:06

The strcat function expects two strings in, not one string and a char.
Also the content[strlen(content)-1] = '\0'; will cut away the last character of the string.
You need to manually append c to the end of content.

int contentlen;

contentlen = strlen(content);
if (contentlen + 2 <= BUF_SIZE){
  content[contentlen++] = c;
  content[contentlen] = '\0';
 }

If you don't intend to work on the buffer as a string then you can of course skip the null termination and just keep track of the length manually until it is time to print the string.

By Manuel

Ascended (18777)

25-09-2015, 23:09

Note that AFAIK, the \0 is already added by strcat, so you shouldn't have to add it yourself. (At least if this strcat behaves like the modern strcat...) But it doesn't explain the garbage, of course.

By Sylvester

Hero (554)

25-09-2015, 23:51

Thanks @bore, your solution works!

An other small question, what does the MSX-C manual write about the convention for function names? Because when I look in the .MAC file i see for example:

	public	init@c
	public	main@
	extrn listco
	extrn	 printu
	extrn	 printv
	extrn	 optopt
	extrn	 prints
	extrn	 printc

It only lists the first 6 letters of my function names. Does that mean the first 6 letters of a function name have to be unique?

By anonymous

incognito ergo sum (116)

26-09-2015, 06:55

AxelStone wrote:

Basically you can split between declaration and definition of variable, so .h files and .c files does they are supposed to do and your code is more legible. Here goes how you should declare extern variables:

Yes, that's similar to what I do. I have a file for each function (main.c, func1.c, func2.c, etc), and a single header with all the declarations (whatever.h). Then I have two .BAT scripts: MAKELIB.BAT compiles all the functions and links them into a library file. MAKE.BAT compiles main() and links the whole program.

I find this method much faster.