Jump to content

42bs's Photo

42bs

Member Since 4 Mar 2003
OFFLINE Last Active Apr 9 2019 4:23 AM

#4253878 C compilers?

Posted by 42bs on Mon Apr 8, 2019 10:46 AM

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

 

 

Rather:

moveq #-8,d0

and.l #end+7,d0

 

or better (if the assembler can handle it):

move.l #( end+7 )  & ~7,d0

 

Note: Don't waste cycles on-line you can invest off-line.


  • ggn likes this


#4252242 C compilers?

Posted by 42bs on Fri Apr 5, 2019 1:08 PM

Anything is just fine with the C code. And gcc treats char as byte. And alignment is no problem for byte accesses.

So the root cause is something else.

 

If -S does not work, just try objdump -dS with the resulting object file to see the assembly.

 

BTW: Lauterbach (lauterbach.de) offers simulators for free. I use them often to inspect suspicious code.




#4231683 gcc for 6502 (kinda)

Posted by 42bs on Mon Mar 4, 2019 1:43 AM

Hi

just an idea I am going "pregnant" for some time. And now a small prove of concept works.

 

Here the basic idea: GCC is very good in optimizing, but only supports 16 and 32 bit CPUs. So first I thought to port it to Sweet16. But then (while discussing with someone who develops an audio book for developing countries) I got a better idea: Cortex-M0.

 

The Cortex-M0 has an very limited ISA but is very well supported by gcc (and other commercial compilers).

 

So, I tried to compile C to assembly, then throw away unneeded stuff and do some modification to get a version which can be fed to lyxass.

 

In a first step, I just replace the CM0 opcodes 1:1 by 65SC02 ones, like this:

 

 movs rn,rm

=>

    macro movs
    lda regs_lo+\1
    sta regs_lo+\0
    lda regs_hi+\1
    sta regs_hi+\0
    endm
 

Of course, it will result in a code-explosion, so the next step would be to write an interpreter and generate opcodes for this with the macros.

Kind of Sweet16-reloaded.

 

Cheers




#4224388 C compilers?

Posted by 42bs on Thu Feb 21, 2019 11:27 AM

It should align data on the natural boundary, that is char on byte, short on two and int on four bytes.

 

From gnu.org:

-malign-int

-mstrict-align




#4223554 Atari Lynx programming tools and tutorials (wip)

Posted by 42bs on Wed Feb 20, 2019 6:09 AM

 

What is "structural assembly"?

 

Something like this:

  bit MATHE_AKKU
  _IFMI
    inc temp
    _IFEQ
      inc temp+1
    _ENDIF
  _ENDIF

Like in Pascal.

The macros hide the the branches.

 

Or:

 ldx #16
 _WHILENE X
   sta $fda0-1,x
   dex
 _WEND

See if_while.mac


  • jum likes this


#4223545 Atari Lynx programming tools and tutorials (wip)

Posted by 42bs on Wed Feb 20, 2019 5:51 AM


So I wonder if BLJ and BLL could be extended to BLC also? (C - for linkable with C-code)

 

I really like the idea of structural assembly. It makes reading the code much easier.

 

You mean, using an intermediate object format?

I doubt that this is an easy task to do.

For the Jaguar I do not see much of a benefit, as you can always export the symbols from lyxass and then import them in a stub assembly file together with the binary.

The GPU/DSP code needs to run in the internal RAM anyway, so not much of a code movement.

 

For cc65, this would be interesting. But it is likely easier to change ca65 to accept lyxass macro syntax.




#4220270 C compilers?

Posted by 42bs on 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.




#4219235 C compilers?

Posted by 42bs on 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.




#4218370 C compilers?

Posted by 42bs on Tue Feb 12, 2019 4:58 AM

If it works don't touch it XDXDXD

 

Maybe I'll try that later, but anyway although my method has more steps, it works and with todays computers it doesn't matter because it's fast.

 

more steps == more possible bugs ;-)


  • ggn likes this


#4218272 C compilers?

Posted by 42bs on Mon Feb 11, 2019 11:52 PM

Ok, g++ is just the driver. So you use GNU ld. So why bother with a Atari ST GCC? And TOS output?

 

GNU ld is very powerful, so you can nearly anything you want. Output an absolute ELF, then use objcopy to generate the binary.

 

Not need to hassle with tos2jag, relocation etc.

 

Do you need C++14 features? If not, you can just use any m68k-elf-gcc around.

 

BTW: "brownout" is a strange word used here. Coming from embedded, "brownout" defines the moment just before "blackout" ;-)




#4215453 Upcoming Jaguar SD Cartridge

Posted by 42bs on Fri Feb 8, 2019 2:51 AM

Awesome update!

 

Not sure if I missed it in the video, but will the CD support also have MemoryTrack emulation, or will all the CD games be unable to save?

 

Awesome update!

 

Not sure if I missed it in the video, but will the CD support also have MemoryTrack emulation, or will all the CD games be unable to save?

 

See: http://atariage.com/...dpost&p=4210741




#4214184 Is 10 FPS a too low framerate for a LYNX tile based game?

Posted by 42bs on Wed Feb 6, 2019 7:18 AM

T-Tris does not only save the high-score, but also the game when paused on EEPROM. You can turn off the Lynx and continue later ...




#4211057 GPU with mutiple interrupts

Posted by 42bs on Fri Feb 1, 2019 1:51 PM

BTW would anyone like to post a small working example of this so everyone will get some closure? :)

 

I am currently reworking the BJL examples for rmac/rln/tj_ass.


  • ggn likes this


#4210618 GPU with mutiple interrupts

Posted by 42bs on Thu Jan 31, 2019 11:22 PM

IRQ runs on register bank 0!

 

14  REGPAGE  Switches from register bank 0 to register bank 1. This function is
overridden by the IMASK flag, which forces register bank 0 to be used.

 

See my previous post!




#4209711 GPU with mutiple interrupts

Posted by 42bs on Wed Jan 30, 2019 11:13 PM

Are you sure you've selected bank 1 for the foreground code?

When switching bank, you should not use any register for at least 2 cycles:

 

    movei    #1<<14|%11111<<9,r1    ; clear all ints, REGPAGE = 1
    store    r1,(status)
    nop
    nop                ; wait
    moveta    status,IRQ_FLAGADDR.a