C compilers?

[ggn]

Other random thought: are you using link time optimisation (-flto)? This can seriously mess up the order of object files.

[swapd0]

Other random thought: are you using link time optimisation (-flto)? This can seriously mess up the order of object files.

 

Yes, I'm using -flto, I'll have a look later.

 

Maybe the solution it's to write my elf to jag executable and put the jmp _start at the beginning.

 

Doing the relocation at the jaguar it's "impossible" at development time, because I've the rom with the assets into a "filesystem" block at rom, and I upload the code at ram.

 

------------- Added -------------

 

Without -flto it gives a linker error, undefined reference to _malloc at zerolibc.cpp, although that's for C++.

Edited December 13, 2018 by swapd0

[ggn]

Without -flto it gives a linker error, undefined reference to _malloc at zerolibc.cpp, although that's for C++.

Did you rebuild everything from scratch without -flto? Both compiler and linker settings have to be in sync.

[swapd0]

Did you rebuild everything from scratch without -flto? Both compiler and linker settings have to be in sync.

 

Yes, I did a make clean, and removed all .o files at libcxx directory.

[swapd0]

I've written a program to relocate the TOS file generated by brownout to the address 0x4000, for now it looks good.

 

Now it's time to test it with a real program...

[swapd0]

Why my functions don't get exported when I compile some files into a static library?

 

I'm using these parameters:

 

CFLAGS = -Ofast -fomit-frame-pointer -fstrict-aliasing -fcaller-saves -flto -ffunction-sections -fdata-sections -fleading-underscore -fvisibility=default -Wall

I've also tried to put extern or __attribute__ ((visibility ("default"))) at the beginning of the function but the function it's not exported. When I call nm -g libjaguar.a the only symbols that I get are from some assembler files, but no symbol from C code.

[swapd0]

Fixed, just remove -flto flag

[ggn]

One thing I'm puzzled over this approach is what would you do when you want to create a rom file where text+data won't be contiguous with the BSS - perhaps it would be best to modify brownout directly for this?

[swapd0]

I thought that BSS it's always at the end, first text, then data, and bss at the end.

 

I think that I'm going to have some problems with mallocs, because they will ask to the OS for a memory chunk.

[ggn]

Well, my thought was that you are going to run a binary that gcc/ld/whatever else outputted in ROM directly. Then your code and data will be at $802000, and the bss will have to be in main RAM. But if you plan to copy the binary from ROM to RAM and run it there, no problems.

[swapd0]

Bump!!!

 

I've compiled a sprite test with gcc and it "works"...

I mean, it compiles and executes ok, but I had to define the following functions to avoid linker errors, and of course the program doesn't work properly. Where can I get a small free/malloc functions? I've been "googling" but I want a small and simple version. Also I don't know why I need the memset because it was defined in brownboot.s.

void free(void *ptr)
{
	skunk_print("free\n");
}

void *malloc(size_t bytes)
{
	skunk_print("malloc\n");
	return 0;
}

void *calloc(size_t n, size_t bytes)
{
	skunk_print("calloc\n");
	return 0;
}

void *memcpy(void *dst, const void *src, size_t bytes)
{
	skunk_print("memcpy\n");
	return 0;
}

void* memset(void* dst, int v, size_t bytes)
{
	skunk_print("memset\n");
	return 0;
}

Edited February 5, 2019 by swapd0

[ggn]

Lately I've seen one person using https://github.com/thi-ng/tinyalloc

[LinkoVitch]

Dynamic memory management isn't too difficult to code from scratch, you might benefit from a custom Jaguar specific written one also. If you are say allocating RAM for a bitmap or OP list you are going to want it correctly aligned in memory, using stock generic managers might make more work for you ensuring you request excess RAM and determine correct alignment within. If you wrote your own you could specify any alignment requirements in the request and have the system nicely return memory appropriate to your needs.

[ggn]

Dynamic memory management isn't too difficult to code from scratch, you might benefit from a custom Jaguar specific written one also. If you are say allocating RAM for a bitmap or OP list you are going to want it correctly aligned in memory, using stock generic managers might make more work for you ensuring you request excess RAM and determine correct alignment within. If you wrote your own you could specify any alignment requirements in the request and have the system nicely return memory appropriate to your needs.

 

From the page I linked:

 

TA_ALIGN 8 Word size for pointer alignment

TA_BASE 0x400 Address of tinyalloc control data structure

TA_DEBUG undefined Trace debug information

TA_DISABLE_COMPACT undefined Disable free block compaction

TA_DISABLE_SPLIT undefined Disable free block splitting during re-alloc

TA_HEAP_START 0x1010 Heap space start address

TA_HEAP_LIMIT 0xffffff Heap space end address

TA_HEAP_BLOCKS 256 Max. number of memory chunks

TA_SPLIT_THRESH 16 Size threshold for splitting chunks

 

I think all that pretty much covers what you said?

[LinkoVitch]

Yeah, but... *sulks*

[swapd0]

It's not very complex but (for this) I prefer to use some already tested code than doing it by myself.

 

I don't understand this.

uint32_t *_op_objects = NULL;

void init_sprites(int16_t lists, int16_t sprite_count)
{
	video_off();

	if ( _op_objects != NULL )
		free(_op_objects);

   ...
}

free call it's executed, WTF!?!?! It's supposed to be initialised with NULL.

[LinkoVitch]

Perhaps the compiler isn't setting the variable with NULL correctly? perhaps try manually setting it to NULL in code before calling init_sprites? see if that resolves it, will tell you if compiler is doing it correctly... Or something somewhere is overwriting that variable/populating it?

[swapd0]

Ok, I got the sprite test running (at last!!!!).

 

The problem that I talked about it was because I set the HEAP_START just after the label __fini_array_end, that I was supposing that it was at the end of my program (wrong!!!!!). To fix this I've put the heap address at 1MB, it's a bad solution but at least I see that the compiler, and everything else works.

 

I'm generating a TOS executable and then I relocate the program at 0x4000 and it works, to fix my crap solution I need to put the heap start address at the end of my program (text + data + bss), for now the only solution that I've is to change the relocation program to include the program size at the beginning, just after the first opcode (it's a jmp), then the ta_init() function will read this size to know the heap start address.

 

Any better idea?

Edited February 6, 2019 by swapd0

[LinkoVitch]

Can you not define a label at the end of your program BSS and then use that as the heap location?

 

For safety i'd make sure it's at least phrase aligned in RAM though. From what GGN showed earlier I suspect that if the heap is long aligned the malloc will not adjust it for alignment.

[swapd0]

Don't worry, I've changed TA_ALIGN to have always 32bytes alignment for scaled bitmap objects.

 

I'll try the label at the end... the problem it's to know which file it's the last one, or maybe I can create a file with a single label and link it the last one.

[Sporadic]

Don't worry, I've changed TA_ALIGN to have always 32bytes alignment for scaled bitmap objects.

 

I'll try the label at the end... the problem it's to know which file it's the last one, or maybe I can create a file with a single label and link it the last one.

As mentioned above, from what I've seen, (I think it was Chequered Flag) there was a last.s which just included the relevant labels. That was the last thing linked to.

[swapd0]

I've managed to include the heap bas at the end, you must put it as the last file but not into a symbol with all objects files.

 

I've seen that there is a symbol (_end) that it's always the last one

...
00009764 B _end
00002168 T _end_sprites
0000143c T _exist_multitap
00000000 T _exit
000091cc b _exit_count
000082a8 b _exit_funcs
00003424 T _fade_palette
000004e2 t _fmtint
000090c0 b _frame_buffer
00006060 d _frame_metadata
000091b4 b _frame_sprite
00000ff8 T _free
00009760 B _heap_start
...

Anyway, if I use _end or _heap_start + 32 (If I use _heap_start it doesn't work) as the start heap address I get an error from brownout.

error: reference 0x00009764 points at an area not mapped by existing sections

Edited February 7, 2019 by swapd0

[swapd0]

Fixed.

[swapd0]

Cool, now it looks like I've the data miss-aligned, and I'm using a .phrase before the data.

 

Here are the labels from the ELF file.

00006178 D _bmp2
00006280 D _bmp4
00006488 D _bmp8

And now the same labels from TOS file.

_bmp2 D 00004b42
_bmp4 D 00004c4a
_bmp8 D 00004e52

Edited February 7, 2019 by swapd0

[LinkoVitch]

Take the address you get from end and make sure it is phrase aligned

move.l #end,d0
add.l #8, d0
and.l #$fffffff8, d0

Will leave you with a phrase aligned address in d0

Edited February 8, 2019 by LinkoVitch