some doc - Page 1

As I'm new to the kernel world, I'm looking for some doc about the libraries graphlib, userlib etc....
Is there some relevant doc existing ? Or there are only the header files ?

oups... I haven't read the correct headers.
The correct ones are in fact sufficient.

and the doc on ram_calls is provided with PreOS

I have all the same a question : can I use it in C ?

graphlib::choosescreen	equ	graphlib@000D
;--------------------------------------------------------------
;	graphlib::choosescreen is a word sized variable.
;
;	If it is null, the adress of the screen for every graphlib
;	 function will be LCD_MEM
;	Else, the adress of the bitplane you want graphlib to use on
;	 will be stored in a1
;
;	This allows you, for example, to use all graphlib functions
;	 with grayscale !
;--------------------------------------------------------------

I think I should use some asm("...a1=myscreen...") for each graphlib call, even if the value of myscreen don't change in the whole function.


just a note : I have passed my library from DLL to LIB, I have saved about 10 ko ! (40 to 30). strange ?

Yes you can. You just have to throw tigcclib.h and its friends out and use the headers provided with PreOS (in a subfolder looking like 'sdk') instead

Sorry, I haven't been clear in my question. I already use some graphlib function, but with LCD_MEM, in doing graphlib_choosescreen = 0
the problem is that sometimes, I would like to draw in some specific memory, in some buffers.
At the basis, in C, there no control on the registers. But maybe with asm("...."), I can do something... ?

I don't understand your problem.

can I do something like that ?

drawSomeThing(prameters..., void * screen) {
  graphlib_choose = 1;
  set "a1" = screen;
  .....
  graphlib_line(.....);
  .....
  graphlib_line(.....);
  .....
  graphlib_fill(....);
}

Or I'm obliged to do something like that ?

drawSomeThing(prameters..., void * screen) {
  graphlib_choose = 1
  .....
  set "a1" = screen;graphlib_line(.....);
  .....
  set "a1" = screen;graphlib_line(.....);
  .....
  set "a1" = screen;graphlib_fill(....);
}

I think you should do that :
In your .h :
void graphlib_put_sprite_custom(unsigned short x asm("d0"), unsigned short y asm("d1"), void *sprite asm("a0"),void *dest asm ("%a1"));

In a .s file :

 xdef graphlib_put_sprite_custom
graphlib_put_sprite_custom:
  jmp graphlib__0001

Unfortunately, we can't overload functions in C. If we could, we would only have to had a #define graphlib_put_sprite_custom graphlib__0001 in the .h file, without writing any line of assembly.

[edit] : Oups, I wrote an imbecility.

But I thought about another way to use graphlib functions with an additional parameter :
In your .h file :

#define USE_CUSTOM_GRAPHLIB \
#undef graphlib__0000 // fill \
#undef graphlib__0017 // line \
void graphlib__0000(unsigned short x asm("d0"), unsigned short y asm("d1"), unsigned short width asm("d2"), unsigned short height asm("d3"), unsigned short color asm("d4"),void *dest asm("%a1"));  \
void graphlib__0017(unsigned short x1 asm("d0"), unsigned short y1 asm("d1"), unsigned short x2 asm("d2"), unsigned short y2 asm("d3"), void *screen asm("a0"),void *dest asm("%a1"));

#define END_USE_CUSTOM_GRAPHLIB \
#undef graphlib__0000 // fill \
#undef graphlib__0017 // line \
void graphlib__0000(unsigned short x asm("d0"), unsigned short y asm("d1"), unsigned short width asm("d2"), unsigned short height asm("d3"), unsigned short color asm("d4"));  \
void graphlib__0017(unsigned short x1 asm("d0"), unsigned short y1 asm("d1"), unsigned short x2 asm("d2"), unsigned short y2 asm("d3"), void *screen asm("a0"));

In your .c files :

drawSomeThing(prameters..., void * screen) {
  graphlib_choose = 1;
  USE_CUSTOM_GRAPHLIB;
  .....
  graphlib_line(.....);
  .....
  graphlib_line(.....);
  .....
  graphlib_fill(....);
  END_USE_CUSTOM_GRAPHLIB;
}

(note : I didn't test it)

OK, thank you. I think I would use the #define solution.

Hum, it doesn't seem to work

No it doesn't.

test.c:33: error: conflicting types for `graphlib__0000'
graphlib.h:4: error: previous declaration of `graphlib__0000'
test.c:33: warning: extern declaration of `graphlib__0000' doesn't match global one
test.c:42: error: conflicting types for `graphlib__0000'
test.c:33: error: previous declaration of `graphlib__0000'

the undef doesn't do the job you intend to do. It only undefine macros, not function prototype.

But if I add the argument void *dest asm("%a1") in the header file (the "kernel.h"), it works correctly.

When I was thinking about a macro, I was thinking about something like that :

#undef graphlib_fill
#define graphlib_fill(x1,x2,y1,y2,color,screen)   asm("move.l screen,%a1");graphlib__0000(x1,x2,y1,y2,color);

You can still use the solution given in ./9

Sasume :
But I thought about another way to use graphlib functions with an additional parameter :
In your .h file :

#define USE_CUSTOM_GRAPHLIB \
#undef graphlib__0000 // fill \
#undef graphlib__0017 // line \
blablabla

You can't write stuff like that in C (actually, you can, but it won't do what you think it does )
You can't have a preprocessor command in a #define (the preprocessor will in fact believe that you want to stringify the macro parameter 'undef', which does not exist).
What's more, \s are interpreted at a very early stage, meaning your statement really is
#define USE_CUSTOM_GRAPHLIB #undef graphlib__0000 // fill #undef graphlib__0017 // line blablabla
which is equivalent to
#define USE_CUSTOM_GRAPHLIB #undef graphlib__0000

In fact, that was even a feature that was available in early versions of GTC (with a different command, #macro)



Hibou> things don't work like that in C, because the compiler could do weird magic between your assignment to a1 and the actual function call. And the default calling convention provides no way to specify that a1 is not destroyed by the function call (I even think you can't change that without recompiling GCC -- don't quote me on this though). Basically, it would be very dirty to do that, and I really don't think you need such a high level of optimization when calling such a slow library... Just declare it as a parameter and pass it every time you need it.

Well, there is a tigcc flag that tells the code generator never to use a specific register. Still, it is a *bad* idea, because the register becomes unavailable to the generator in all your code. Doing this will generate less efficient, and probably bigger code (as the compiler will have to store more variable in the stack and generate additional instructions to load and store them).

and chances are that if this register is a scratch register (as is A1), undefined behaviours could happen (though, as usual with GCC extensions, it probably isn't specified anywhere )

But if I add the argument void *dest asm("%a1") in the header file (the "kernel.h"), it works correctly.

It is the best solution!

Do you want I add this parameter in kernel.h?
I have forgotten it when I write this header.

Yes, I would need this parameter, but this will bring incompatibilities with other programs ? no ?

And in fact, I had problems with the "kernel.h".
tigcc return me :

scrStudy.c: In function `h_scrStudy':
scrStudy.c:458: error: syntax error before "__pshort"

the line 458 of scrstudy.c :

Parms2D(Parse2DExpr(top_estack,FALSE), &width, &down, &up);  //get the dimensions

with this :

#define USE_KERNEL
#include "kernel.h"
int _library;
int	_version09;

To do my first tests, I copied the graphlib prototypes in a special file and there is no problem with :

#define USE_KERNEL
#include <tigcclib.h>
int _library;
int	_version09;
#include "graphlib.h"

By the way, why coping every header of tigcclib in kernel.h ? why not my second solution ?

You can find __pshort in a the TIGCC default.h IIRC.
Why kernel.h messes up as usual is another story...

hibOu :
Yes, I would need this parameter, but this will bring incompatibilities with other programs ? no ?

Are there any programs that actually use these headers? </troll>

By the way, why coping every header of tigcclib in kernel.h ? why not my second solution ?

TIGCCLIB hasn't been designed to support Kernel Programs properly.

Are there any programs that actually use these headers? </troll>

Oui.

PpHd
:

Are there any programs that actually use these headers? </troll>

Oui.

And are these programs large enough to actually use graphlib_fill?