LCC for the Gigatron. Take two.

[lb3361]

It is an excellent tool in gaining more vCPU time for your application, the only real issue with it is that the final output of the mixed 4 channel audio samples is never output to XOUT during the blanked scanlines. So depending on your application, how much audio it uses and how many scanlines you blank, some audio distortion will invariably be introduced.

I also noticed that frameCount is counting too slowly if you set videoTop_v5=240, but correct if you leave one displayed scanline with videoTop_v5=238. Is this the same bug?

Update: I checked the code and realized, as explained by at67, that sound is not processed while scanlines are blanked by videoTop_v5. In addition, when one sets videoTop_v5 to 240, the code that tests that one has reached the end of the screen is skipped. This not only means that frameCount is wrong (apparently halved) but also that the signal sent to the monitor makes no sense. Therefore the highest value one should give to videoTop_v5 is 238, leaving a single row of pixels at the bottom of the screen (which could be useful anyway).

[lb3361]

I spend some time hacking the lcc common code to support two new keywords, __near and __far. They keywords act as type qualifiers like const or volatile and are supposed to indicate where variables of that type should be allocated.

I hope that, in a distant future, variables declared with __far types will live in banked extension memory. However this requires a lot of additional work because one needs to modify the lcc common code to deal with pointers of different sizes, and, in order to have reasonable performance, one also needs to define new vCPU instruction to peek/poke far pointers.

However there is already a very valuable use. Variable declared with __near types are placed in page zero. The linker keeps track of the remaining page zero location and transparently allocate space for these variables. The compiler is informed of their location and can generate more compact code to manipulate them.

• The first application was to rewrite the <gigatron/sys.h> file. This file used to give access to the standard Gigatron variables using clumsy defines. Now it simply contains a collection of extern __near declarations. The actual locations are then provided by the interface.json file.

  Code: Select all

  extern __near byte zeroConst;
  extern __near byte memSize;
  extern __near byte entropy[3];
  extern __near byte videoY;
  extern __near byte frameCount;
  extern __near byte serialRaw;
  ...
  

• The second application was to save a lot of console code by storing the console state in page zero. The main effect was added by simply adding the keyword __near to both the declaration and the definition of variable console_state.

  Code: Select all

  extern __near struct console_state_s {
  	int  fgbg;		/* fg and bg colors   */
  	char cy, cx;		/* cursor coordinates */
  	char wrapy, wrapx;	/* wrap/scroll enable */
  } console_state;
  

  The console code also used to cache pointers to the console_state variables in order to produce better code. This was no longer useful. This simple changes saves 150 bytes on program sizes. For instance the sieve programs are down to 2500 bytes.

[veekoo]

I downloaded latest GLCC version compiled it and ran "make test". It gives a lot of error? "(gtsim) Horizontal timing error:vgaY -36, vgaX 9 , t=478.850".

Edit. Shortly after this post GLCC was repaired and now it works again.