Jump to content
Jagware
Sign in to follow this  
Michael

using jlibc-0.5.10 with vbcc for Jaguar Development

Recommended Posts

Michael    0

Hello,

 

i tried to make use of my SkunkBoard and write some small software for the jaguar under Linux. After try out gcc and vbcc i was first successful with vbcc, so i go ahead with vbcc. GroovyBee has a nice description about Developing in "C" in windows xp which can be used as a guide. I have used the config files for the linker from his description and used the same directory tree for my source files:

 

+-- cfg

+-- jlibc-0.5.10

+-- first

+-- jaglib

 

On the Linux development environment it was not necessary to change the directory structure inside the jlibc. But some modifications are needed:

 

  • I have added the long arithmetic functions from vbcc to the jlibc
  • Some C++ comments must be replaced by C comments
  • Some macros in stdlib.h (isgigit, ...) are replaced by functions.
  • memcopy functions are done by blitter (taken from Atari source)
  • increase the alignment of malloc from 8 (Phrase) to 16 (Page). Otherwise my Jag did not display a object list located in dynamically allocated memory.

 

To allow the usually way to link a C program (crt0 (startup code), main(), objects, libs) i made some additional changes:

 

  • crt0.s is very close to the startup.s from Atari and many other examples. This startup did not contain a object list to allow the user to choose a library he likes. The startup code jumps to __main() from start.c
  • start.c makes all initializations for the jlibc and then jumps to main() Note: this version did not pass any arguments to main()! This version did also not take care of the difference between running from cartridge or running from ram (by skunk). This can be added in the same way than described in the description from GroovyBee.

 

My patch can be retrieved from my Homepage: vbcc patch for jlibc-0.5.10

 

I have also a small first.c for show, how to integrate the jlibc: first.c

 

The creation of the object list for my first.c was put in a small library: jaglib. My small lib was no replacement for the removers lib or the raptor lib. So the handling of the object list in first.c can also be done with the use of a more powerful lib.

 

My make use also a tool written by me for add/remove the jag header: Some jag Tools

 

I hope, some find my patches useful for its work.

 

Happy hacking and best regards

Michael Bernstein

Share this post


Link to post
Share on other sites
SebRmv    2

That's interesting. I'll have a look at your patches to see if some can be integrated to jlibc directly. (remove C++ comments, ...)

 

Regarding the memcpy done by blitter by default, I don't think it is a good idea. This is funny because I had a talk with Matmook at the latest RGC and we agreed that implicit calls to blitter are never a good idea.

 

I think it's better if the programmer has the complete control on how he manages the blitter. Imagine for example that you call a GPU rendering routine that uses the blitter, and that concurrently your m68k code calls memcpy: with your approach, this will fail.

This scenario may happen because the C compiler may insert some calls to memcpy/memset when complex struct are copied/initialized.

 

That is why I made the choice to have pure m68k version of memcpy/memset in jlibc.

However, in rmvlib, I have defined two functions blitcopy/blitset that have the same API as memcpy/memset but these functions use the blitter. If the programmer wants to make fast memory transfers, then he explicitly uses the blitter (and thus he is aware that the blitter cannot be used concurrently by another "thread")

 

Cheers

 

Seb

Share this post


Link to post
Share on other sites
Michael    0

Hi Seb,

 

That's interesting. I'll have a look at your patches to see if some can be integrated to jlibc directly. (remove C++ comments, ...)

 

I think, it is possible to add some of the changes which are not really compiler specific. Maybe it is also possible to make the build process depending on a define for the compiler gcc/vbcc in the makefile to make the decision, which files to buidl.

 

If you want to glue the jaguar startup code together with start.c and main() depends on your taste. I'd like this idea for my projects.

 

Regarding the memcpy done by blitter by default, I don't think it is a good idea. This is funny because I had a talk with Matmook at the latest RGC and we agreed that implicit calls to blitter are never a good idea.

 

I think it's better if the programmer has the complete control on how he manages the blitter. Imagine for example that you call a GPU rendering routine that uses the blitter, and that concurrently your m68k code calls memcpy: with your approach, this will fail.

 

Ok, this is a good reason. I have used the blitter because it was in an example from Atari itself.

 

If you like to make your lib working with gcc and vbcc feel free to ask me for testing with vbcc.

 

Regards

Michael

Share this post


Link to post
Share on other sites
SebRmv    2

Hi Michael,

 

what was wrong with crt0.s in jlibc? I don't think I understood the reason why you changed it.

 

Cheers,

 

Seb

 

PS: I just backported some of your patches to github repo, thanks again for your work. (https://github.com/sbriais/jlibc)

 

Just for my information, is it the case that vbcc does not support

- constructions like *(x++) = y and

- variable declarations anywhere else than at the beginning of a block?

 

PPS: where can I get vbcc?

Share this post


Link to post
Share on other sites
Michael    0

Hi Seb,

 

what was wrong with crt0.s in jlibc? I don't think I understood the reason why you changed it.

 

Your crt0.s calls _main which is main() in C. Your init function of start.c is __main() which is ___main in assembler. So the init function of the jlibc is never called automatically. Instead your startup code jumped directly to the main function of a user.

 

I let crt0 call the init function of start.c ___main in assembler and __main() calls main(). You can instead call main() from crt0.s I don't know, what is the usual way. But usually the initialization of the c lib is done automatically from the startup code and not from the user.

 

I made also some other modifications. The ctr0.s was derived from the startup examples from Atari. This code defines a object list with 1 bitmap an initializes the graphic system. The initialization of the graphics system set some variables e.g. screen width and screen height. I have used global variables which i can access from C (leading _) and modified the name. So i was able to initialize a object list with the same bitmap than the Atari examples from C in my main() function. Your crt0.s hides these values. This is more important for my own code. But i think, to make these variables visible to other functions is also useful for others. We can check, if the other Jaguar libraries like the raptor lib or the removers lib uses these variables.

 

For the memory management i made also a modification. I have a variable _end which was used inside start.c for set get the address of the unused memeory ínstead of BSS_E. This is also vbcc specific.

 

PS: I just backported some of your patches to github repo, thanks again for your work. (https://github.com/sbriais/jlibc)

 

thank you :-) So my work was useful for others.

 

Just for my information, is it the case that vbcc does not support

- constructions like *(x++) = y and

 

I think, this should not be a problem. My test program did not generate a compiler error. But i often like to split such statements. Sometimes for debugging. I am not a friend of very short statements which are possible in C. For me it is more easy to understand the statements if they are not to short. And i think it is the task of the compiler to make such optimization.

 

My test software was:

 

----- ><8 -----

{ char buf[40], *p;

 

p = &(buf[0]);

*(p++) = 'a';

----- 8>< -----

 

- variable declarations anywhere else than at the beginning of a block?

 

It seems yes. vbcc allows variable declaration only at the beginning of a block. Otherwise i got an compiler error:

 

----- ><8 -----

warning 216 in line 17 of "main.c": illegal use of keyword <int>

>int i;

warning 216 in line 17 of "main.c": illegal use of keyword <int>

>int i;

error 82 in line 17 of "main.c": unknown identifier <int>

>int i;

warning 54 in line 17 of "main.c": ; expected

>int i;

error 82 in line 17 of "main.c": unknown identifier <i>

----- 8>< -----

 

PPS: where can I get vbcc?

 

I had to search. I collect all (for me interesting) software for the jaguar and Jaguar development over the last years. And forget to notice the URL. I think, i got at the start of last year many new tools which includes also the vbcc. I have installed them on my netbook before i travel toe the EJag Festival in Duisburg.

 

Best regards

Michael

Share this post


Link to post
Share on other sites
SebRmv    2
what was wrong with crt0.s in jlibc? I don't think I understood the reason why you changed it.

 

Your crt0.s calls _main which is main() in C. Your init function of start.c is __main() which is ___main in assembler. So the init function of the jlibc is never called automatically. Instead your startup code jumped directly to the main function of a user.

 

I let crt0 call the init function of start.c ___main in assembler and __main() calls main(). You can instead call main() from crt0.s I don't know, what is the usual way. But usually the initialization of the c lib is done automatically from the startup code and not from the user.

 

I made also some other modifications. The ctr0.s was derived from the startup examples from Atari. This code defines a object list with 1 bitmap an initializes the graphic system. The initialization of the graphics system set some variables e.g. screen width and screen height. I have used global variables which i can access from C (leading _) and modified the name. So i was able to initialize a object list with the same bitmap than the Atari examples from C in my main() function. Your crt0.s hides these values. This is more important for my own code. But i think, to make these variables visible to other functions is also useful for others. We can check, if the other Jaguar libraries like the raptor lib or the removers lib uses these variables.

 

For the memory management i made also a modification. I have a variable _end which was used inside start.c for set get the address of the unused memeory ínstead of BSS_E. This is also vbcc specific.

 

Ok, I understand. Actually, I think it is gcc vs vbcc issues.

The code generated by gcc calls the function __main from main. So the crt0.s does not need to call it itself.

(see http://gcc.gnu.org/onlinedocs/gccint/Initialization.html the part on __main)

 

Maybe we can tweak something with #ifdef so that the "same" code works with gcc and vbcc.

Is there a macro variable defined by VBCC that indicates that VBCC is the current compiler? I know for sure gcc defines _GNUC_

 

Regarding the defined variables (width, height, ...), I don't really understand your point since I declared globl the following ones in crt0.s:

        .globl  _video_height
        .globl  _a_vdb
        .globl  _a_vde
        .globl  _video_width
        .globl  _a_hdb
        .globl  _a_hde

        .globl  _vblPerSec

 

And these are accessible from C as any other global variables (and are used in rmvlib for instance).

 

The variable BSS_E is generated by madmac and is declared global. Cannot you use it from vbcc?

 

Seb

 

PS: by the way, I am pretty sure that raptor does not use jlibc at all.

Share this post


Link to post
Share on other sites
Michael    0

Hi Seb,

 

Ok, I understand. Actually, I think it is gcc vs vbcc issues.

The code generated by gcc calls the function __main from main. So the crt0.s does not need to call it itself.

(see http://gcc.gnu.org/onlinedocs/gccint/Initialization.html the part on __main)

 

Ok, i did not know this and was wondering, why the code did not call the initialization.

 

Maybe we can tweak something with #ifdef so that the "same" code works with gcc and vbcc.

Is there a macro variable defined by VBCC that indicates that VBCC is the current compiler? I know for sure gcc defines _GNUC_

 

I have to check this.

 

Regarding the defined variables (width, height, ...), I don't really understand your point since I declared globl the following ones in crt0.s:

        .globl  _video_height
        .globl  _a_vdb
        .globl  _a_vde
        .globl  _video_width
        .globl  _a_hdb
        .globl  _a_hde

        .globl  _vblPerSec

 

And these are accessible from C as any other global variables (and are used in rmvlib for instance).

 

It is my personal name convention. So you can ignore this part of my patch.

 

The variable BSS_E is generated by madmac and is declared global. Cannot you use it from vbcc?

 

As far as i remember, i got an error. I can check this again.

 

Best regards

Michael

Share this post


Link to post
Share on other sites
SebRmv    2
Regarding the defined variables (width, height, ...), I don't really understand your point since I declared globl the following ones in crt0.s:

        .globl  _video_height
        .globl  _a_vdb
        .globl  _a_vde
        .globl  _video_width
        .globl  _a_hdb
        .globl  _a_hde

        .globl  _vblPerSec

 

And these are accessible from C as any other global variables (and are used in rmvlib for instance).

 

It is my personal name convention. So you can ignore this part of my patch.

 

Sorry, I still don't get this part.

I just said that in the original crt0.s I provide with jlibc, these variables are declared global and are visible from any other module.

So, what is the issue with these? Is it just a matter of naming?

 

Share this post


Link to post
Share on other sites
Michael    0

Hi Seb,

 

        .globl  _video_height
        .globl  _a_vdb
        .globl  _a_vde
        .globl  _video_width
        .globl  _a_hdb
        .globl  _a_hde

        .globl  _vblPerSec

Sorry, I still don't get this part.

I just said that in the original crt0.s I provide with jlibc, these variables are declared global and are visible from any other module.

So, what is the issue with these? Is it just a matter of naming?

 

I renamed the variables for my use. I used different names because i like the camel convention from Pascal. And i like a prefix which indicates, what part of the system belongs to this. So my names for this variables all start with Vid because they describe the video parameters. There is no need to rename your variables.

 

You can ignore this part of my patch.

 

Best regards

Michael

Share this post


Link to post
Share on other sites
Michael    0

Hi Seb,

 

Actually, I think it is gcc vs vbcc issues.

The code generated by gcc calls the function __main from main. So the crt0.s does not need to call it itself.

(see http://gcc.gnu.org/onlinedocs/gccint/Initialization.html the part on __main)

 

Maybe we can tweak something with #ifdef so that the "same" code works with gcc and vbcc.

Is there a macro variable defined by VBCC that indicates that VBCC is the current compiler? I know for sure gcc defines _GNUC_

 

The official documentation at http://www.compilers.de/vbcc.html says, VBCC defines __VBCC__

 

I have checked this and i was able to identify vbcc with the define __VBCC__

 

Best regards

Michael

Share this post


Link to post
Share on other sites
SebRmv    2
Hi Seb,

 

        .globl  _video_height
        .globl  _a_vdb
        .globl  _a_vde
        .globl  _video_width
        .globl  _a_hdb
        .globl  _a_hde

        .globl  _vblPerSec

Sorry, I still don't get this part.

I just said that in the original crt0.s I provide with jlibc, these variables are declared global and are visible from any other module.

So, what is the issue with these? Is it just a matter of naming?

 

I renamed the variables for my use. I used different names because i like the camel convention from Pascal. And i like a prefix which indicates, what part of the system belongs to this. So my names for this variables all start with Vid because they describe the video parameters. There is no need to rename your variables.

 

You can ignore this part of my patch.

 

Best regards

Michael

 

Ok, got it!

Share this post


Link to post
Share on other sites
SebRmv    2
Hi Seb,

 

PPS: where can I get vbcc?

 

You can get the vbcc ready for linux from http://www.hillsoftware.com/files/atari/jaguar/

 

Download the file jaguardevlnx.tar.gz

 

The vbcc was located under the path jaguar//jaguar/bin

 

Best regards

Michael

 

Thanks! I will give it a try.

 

Share this post


Link to post
Share on other sites
Michael    0

Hi Seb,

 

The variable BSS_E is generated by madmac and is declared global. Cannot you use it from vbcc?

 

I made a short test:

 

extern char BSS_E[];

int main(int argc, char *argv[])
{  unsigned long sbrk_ptr;

   sbrk_ptr = (((unsigned long)BSS_E+7L) & (~7L));
   for(;;);  /* Infinite Loop.  Alpine users can delete this.  */
   return(0);
}

 

And got the result:

 

michael@netix: /tmp/Jaguar/firstmichael@netix:/tmp/Jaguar/first$ make
vc -DJAGUAR -O2 -c -o main.o main.c
warning 208 in function "main": suspicious loop
vlink -brawbin1 -T../cfg/bjl.link -nostdlib -L/usr/local/jaguar/lib -ljc -ljag -ltos -ljagutil /usr/local/jaguar/lib/crt0.o main.o -o first.bin
bin2jag -s 0x4000 first.bin
if [ ! -h /tmp/test.jag ]; then ln -s /tmp/Jaguar/first/first.jag /tmp/test.jag; fi

 

So i can access BSS_E from vbcc. I think, i have removed BSS_E because i did not ind anywhere the declaration. And i did not know that this is automatically generated.

 

So i think your code should also work with vbcc.

 

Best regards

Michael

Share this post


Link to post
Share on other sites
Guest
You are commenting as a guest. If you have an account, please sign in.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoticons maximum are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×