Jump to content

Photo

C compilers?

c++ cpp

89 replies to this topic

#76 ggn OFFLINE  

ggn

    Stargunner

  • 1,452 posts
  • Location:Athens, Greece

Posted Tue Feb 12, 2019 10:07 AM

Now, I won't pretend I remember all the things we tried when we were working on browncc/brownout, but I'm sure we tried a few things with linker scripts. The results we got was that ld would crash or ignore our scripts with the back then current binutils. So instead of trying to report our issues or hope they magically fix them we just went ahead with-Ttext-segment=0 and then wrote brownout to do the rest of the work. But hey, if that linker script above works, then it's good news!

#77 ggn OFFLINE  

ggn

    Stargunner

  • 1,452 posts
  • Location:Athens, Greece

Posted Tue Feb 12, 2019 10:10 AM

Also, small reminder/updater: http://brownbot.mooo.comis based on Compiler Explorer and lets you see the assembly output as you type your C code immediately! Also, under the "C" section there is now the option to use a couple of ST compilers using a thin emulation layer. It's fun to sometimes see gcc producing worse code than a 90s compiler :).

#78 42bs OFFLINE  

42bs

    Moonsweeper

  • 276 posts
  • Location:Germany/Southest West

Posted Tue Feb 12, 2019 11:51 PM

Also, small reminder/updater: http://brownbot.mooo.comis based on Compiler Explorer and lets you see the assembly output as you type your C code immediately! Also, under the "C" section there is now the option to use a couple of ST compilers using a thin emulation layer. It's fun to sometimes see gcc producing worse code than a 90s compiler :).

 

It is shocking, what horrible code gcc produces sometimes. Esp. Duff's device is a good example where C compilers reach their limit ;-)

Or where careful chosen types (unsigned instead of signed) produce much better code.


Edited by 42bs, Tue Feb 12, 2019 11:54 PM.


#79 swapd0 OFFLINE  

swapd0

    Moonsweeper

  • 380 posts

Posted Wed Feb 13, 2019 7:47 AM

F*******CK!!!!!

 

I've done more testing and it doesn't work.  :mad:



#80 42bs OFFLINE  

42bs

    Moonsweeper

  • 276 posts
  • Location:Germany/Southest West

Posted Wed Feb 13, 2019 8:05 AM

F*******CK!!!!!

 

I've done more testing and it doesn't work.  :mad:

 

Don't get mad. When it comes to gcc/ld I might help. I am fighting with those for the last 25 years, so ...



#81 ggn OFFLINE  

ggn

    Stargunner

  • 1,452 posts
  • Location:Athens, Greece

Posted Wed Feb 13, 2019 10:10 AM

Personally I'd advise to start clean and try out Bastian's tips and nothing else. Those should lead to an absolute binary without much fuss.

#82 42bs OFFLINE  

42bs

    Moonsweeper

  • 276 posts
  • Location:Germany/Southest West

Posted Wed Feb 13, 2019 10:57 AM

Here a small framework (Note: only tested for compilation, not run!):

# Makefile (make sure to replace SPACES with TABs!!)
ALL: jaggy.bin

CC=m68k-atarist-elf-gcc -mcpu=68000
LD=m68k-atarist-elf-gcc -mcpu=68000
AS=m68k-atarist-elf-gcc -mcpu=68000

OBJCOPY=m68k-atarist-elf-objcopy

CFLAGS=-g
ASFLAGS=-g -Wa,--bitwise-or,--register-prefix-optional,--gdwarf2
LDFLAGS=-nostartfiles -nostdlib -Wl,-T,jaggy.ld,-Map,jaggy.map

OBJECTS=jaggy.o cstartup.o _start.o

jaggy.bin: jaggy.elf
        $(OBJCOPY) -Obinary $< $@

jaggy.elf: $(OBJECTS)
        $(LD) $(LDFLAGS) -o $@ $(OBJECTS)


.ONESHELL:
%.o     : %.c
        @echo "CC $<"
        $(CC) -c $(CFLAGS) $<

.ONESHELL:
%.o     : %.S
        @echo "AS $<"
        $(AS) -c $(ASFLAGS) $<

Linker script:
 

/* jaggy.ld */
/* mimimal linker script */

ENTRY(_start)

MEMORY {
       rom (rx) : org = 0x802000, len = 2M-0x2000
       ram (rx) : org = 0x4000, len = 2M-0x4000
}

stack_top = ORIGIN(ram)-4;

SECTIONS {
   .text : {
      KEEP(*(.init))
      *.o(.text)
      . = ALIGN(4);

      /* needed for cstartup */
      __section_init = .;
      LONG(0);
      LONG(0);
      LONG(0); /* dummy, needed for later ROM => RAM copy of code */

      LONG(0);
      LONG(0);
      LONG(0); /* dummy, needed for later ROM => RAM copy of data */

      LONG(ADDR(.bss));
      LONG(SIZEOF(.bss))
   } > ram

   .data ALIGN(8) : {
      *(.data)
      . = ALIGN(8);
   } > ram

   .bss ALIGN(8) : {
      *(.bss)
      . = ALIGN(8);
   } > ram

}

Entry point:

/* _start.S */
        .section ".init","ax"
        .extern stack_top
        .globl _start
        .type   _start,@function
_start:
        lea     stack_top,sp
        /* add jaguar setup here */
        jmp     cstartup

cstartup:

/* cstartup.S */
        .extern main

        .extern __section_init

        .text
        .globl cstartup
        .type   cstartup,@function
cstartup:
        lea     __section_init,a0
        move.l  (a0)+,a1        // text_romstart
        move.l  (a0)+,a2        // text_start
        move.l  (a0)+,d1        // text_size
        beq.s   crt2
        cmp.l   a1,a2           // src == dst => no copy
        beq.s   crt2
crt1:
        move.l  (a1)+,(a2)+
        subq.l  #4,d1
        bne.s   crt1

crt2:
        move.l  (a0)+,a1        // data_romstart
        move.l  (a0)+,a2        // data_start
        move.l  (a0)+,d1        // data_size
        beq.s   crt4
        cmp.l   a1,a2
        beq.s   crt4
crt3:
        move.l  (a1)+,(a2)+
        subq.l  #4,d1
        bne.s   crt3
crt4:
        move.l  (a0)+,a1        // bss_start
        move.l  (a0)+,d1        // bss_size
        beq.s   crt6
crt5:
        clr.l   (a1)+
        subq.l  #4,d1
        bne.s   crt5
crt6:
        jmp main

And last but not least the main function:

/* jaggy.c */
char test1[12];

__attribute((aligned(8))) short fb[320*240];

const char hello[] = "jaggy rulez";

void main(void)
{
  for(;;);
}

When you check jaggy.map, you'll see, that the fb array is really aligned on 8 bytes.
 

The linker script now places everything in RAM. It can be expanded to link for ROM and have code linked for RAM.
 

HTH

 

Edit: Fix stack_top.


Edited by 42bs, Wed Feb 13, 2019 11:24 AM.


#83 swapd0 OFFLINE  

swapd0

    Moonsweeper

  • 380 posts

Posted Wed Feb 13, 2019 12:21 PM

It works with my sprite test, I've changed my makefile and used the linker script, etc and looks ok, even I've changed a few things into my code and still runs.

 

Now I'm gonna try with the st-niccc demo...

 

Thanks a lot.



#84 42bs OFFLINE  

42bs

    Moonsweeper

  • 276 posts
  • Location:Germany/Southest West

Posted Wed Feb 13, 2019 2:32 PM

It works with my sprite test, I've changed my makefile and used the linker script, etc and looks ok, even I've changed a few things into my code and still runs.

 

Now I'm gonna try with the st-niccc demo...

 

Thanks a lot.

 

Great.

 

The next step are overlays ;-) => Different code in ROM linked to the same address in RAM ......



#85 swapd0 OFFLINE  

swapd0

    Moonsweeper

  • 380 posts

Posted Wed Feb 13, 2019 3:21 PM

I've st-niccc running and it's faster...



#86 42bs OFFLINE  

42bs

    Moonsweeper

  • 276 posts
  • Location:Germany/Southest West

Posted Wed Feb 13, 2019 11:54 PM

I've st-niccc running and it's faster...

 

Nice. Because? Now gcc before vbcc?



#87 swapd0 OFFLINE  

swapd0

    Moonsweeper

  • 380 posts

Posted Thu Feb 14, 2019 4:11 AM

 

Nice. Because? Now gcc before vbcc?

 

vbcc generates code as a 32bits processor, it doesn't matter if you use int16_t types, it will read the value, expand to 32bits and do the operation.

 

The speed up it's quite huge, much better than I thought.

 

Edit:

https://twitter.com/...996493603979264

 


Edited by swapd0, Thu Feb 14, 2019 4:48 AM.


#88 swapd0 OFFLINE  

swapd0

    Moonsweeper

  • 380 posts

Posted Fri Feb 15, 2019 5:07 AM

It's weird.

 

I've in classic kong an assembly file with some incbin, I forgot to use .data directive in the file and the makefile puts that data file at the start, it doesn't use the ENTRY(_start).



#89 42bs OFFLINE  

42bs

    Moonsweeper

  • 276 posts
  • Location:Germany/Southest West

Posted Fri Feb 15, 2019 5:44 AM

It's weird.

 

I've in classic kong an assembly file with some incbin, I forgot to use .data directive in the file and the makefile puts that data file at the start, it doesn't use the ENTRY(_start).

 

You mean the linker not the Makefile, I guess.

 

Did you check the map file, if _start.o was included?

 

BTW: If you use sub-directories, you have to add a "*" in front of the files. LD is kinda stupid. If you write "_start.o(.init)" _start.o must be in the same place as the linker script.

If you write "*_start.o(.init)", it can be anywhere.

 

Maybe PM your linker-script and map-file.



#90 ggn OFFLINE  

ggn

    Stargunner

  • 1,452 posts
  • Location:Athens, Greece

Posted Fri Feb 15, 2019 11:48 AM

LD is kinda stupid.


Can confirm - I made it explode in so many weird and wonderful ways while adding elf support to rmac :)




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users