GCC asm() warning suppression options?

[Trev]

How is it with 8/16-bit rotate?

I'll take a look.

2.95.3's behaviour is slightly moot at this point as I'm hoping to use a later version anyway. Still a bit confused by your findings above though. Perhaps this could be down to stormgcc's backend? I was under the impression they hadn't messed about with the m68k compiler part at all.

I don't know. If the source on Alinea's web site is current, we can take a look.

I'm thinking I'll have a go at amigaos targets. I'm building win32 native, non-Cygwin tools, which I'm sure would be useful to others, particularly people that don't want their Cygwin environment hijacked by a single target a la the current solutions out there.

EDIT: The StormC gcc (m68k-storm) is a bit of  a mess. They built a modified m68k-amigaos binutils, added an m68k-storm target to gcc (modified from the Geek Gadgets m68k-amigaos), configured for the target, and then created a bunch of StormC projects to bootstrap the compiler, probably from a vanilla Geek Gadgets install. Funky. Anyhow, I don't have it built yet, but I'm not I'm seeing a benefit to completing it. StormC 4 is based on gcc 2.95.2. It's not difficult to get a new native m68k compiler.

And what I was really interested in is why gcc 4.4.0 doesn't optimize correctly--in fact, worse than gcc 2.95.3 (which still isn't optimal). A shiney new gcc 4.4.0 m68k-*-amigaos* with fixed optimization (for this parituclar issue, anyway) and a native newlib implementation would be, well, shiney.

[Trev]

I've started adding m68k*-*-amigaos* target support to gcc 4.4.0, and I have a freestanding compiler built. There's a bug in the adtools gas parser (or in my build of it), however, that causes assembly like 'jsr a6@(-0x228:W)' to be assembled as 'js a6@(-0x228:W)', resulting in an assembler error. 'jsrr a6@(-0x228:W)' assembles as 'jsr a6@(-0x228:W)', so that's a bit funny. Anyway, I think it has something to do with the way the offsets are parsed. If the bit after -0x is longer than two characters, the parser eats the r in jrs.

So, I need to fix that before I can move forward.

[Trev]

Kind of scary that what started out as what I hoped was a simple "is there an -Wno-complain-about-asm" option turned into this :laughing:

:-) Anything to pass the time.

Do I take it my crazy Machine::rot8/16/32() are still fair game, then?

I think so, yes. A "fixed" gcc should be able to properly reduce and generate optimal code for shift-or operations, however, and after that, the templates will be redundant. There's no reason why you shouldn't/wouldn't continue to use templates, though, if that fits your coding style. You think? I'd still get rid of the direction and width and use a set of overloaded rotate templates, though. ;-) Keep it generic.

[Trev]

I should probably rename this thread "Trev builds gcc 4.4 for m68k target"

Not yet! My track record with finishing hobby projects isn't so great. It might be "Trev got bored porting gcc to m68k-amigaos and watched Red Dwarf and Star Trek instead."

Re: gas, I might be running into a problem with Microsoft's implementation of snprintf, which differs from the ISO C99 definition with regard to when and where to append NULLs. So, 'jsr' is probably being truncated to 'js\0' somewhere, but only if the operands are over a certain length. Maybe there's a buffer that's too small somewhere in code. Anyhow, just guessing, as I ran into a similar problem when cross-compiling vbcc.

[Trev]

Everything post-C89 in the standard C library is considered Microsoft-specific. Their standards efforts are all centered on C++. Based on press, I gather they're doing a pretty good job, but I don't write much C++ code. There's always the "C++ as a better C" argument to fall back on....

EDIT: And no direct references to *snprintf in gas. So, need to do some debugging.

EDIT2: Well, it's actually operands of a specific length that pose a problem:

Code: [Select]

jsr a6@(-60  :W)   <-- 2 spaces no error
jsr a6@(-60   :W)  <-- 3 spaces ERROR 'js a6@(-60:W)'
jsr a6@(-60    :W) <-- 4 spaces no error

Building a Cygwin cross right now to see if there's a difference between the two runtime environments.

EDIT3: Same problem under Cygwin, so it's probably a bug in gas. Yay. I can work around it by using decimal values for library offsets in inlines, but blah, do I really want to modify those by hand? I guess I'll change fd2pragma and generate the headers again.

EDIT4: Or I could just pad the expressions in macros.h with enough spaces to prevent the error from occurring, which is what I've done.

[Trev]

I'm struggling with read-only data placement at the moment. As the loader begins execution at the start of the first code hunk, all read-only data needs to be placed after code. GCC (supposedly) does this with a target macro, CONSTANT_POOL_BEFORE_FUNCTION. I've defined that macro as 0, which should tell the output routines to do what I want them to do; however, they're ignoring the value. At least, that's how it appears. Read-only data is still being generated before functions, so my hello.c test starts executing in the string "dos.library". Gotta love it. I could force all read-only data into a data hunk, but that shouldn't be necessary. :-/

[Trev]

No answer on '#define CONSTANT_POOL_BEFORE_FUNCTION   0' yet, so I'm forcing everything into a data hunk with '#define READONLY_DATA_SECTION_ASM_OP   "\t.data"'. Obviously, that's not a viable long-term solution, but it keeps things moving. I'll have to ping the GCC gods on why CONSTANT_POOL_BEFORE_FUNCTION isn't working.

[Trev]

Hmm. That's pretty bad. I don't know enough about the internals to be much help. Is CONSTANT_POOL_BEFORE_FUNCTION supposed to suppressed via #define CONSTANT_POOL_BEFORE_FUNCTION 0 or #undef CONSTANT_POOL_BEFORE_FUNCTION ?

Perhaps the switch depends on wether it is #defined at all, rather than what it is #defined as?

Defining to 0 should be the way to go. If undefined, the compiler defines it as 1. It's only checked in two locations (before and after writing a compiled function to assembly source), but it's an old option, only used by one mainline target. It's possible the option has been inadvertently deprecated by the current maintainers.

[Trev]

Moving right along. I'm using the Geek Gadgets patches as a reference, but I'm not merging them. ixemul and libnix will be gone (to be replaced by newlib), as will simple (but annoying) things like legacy built-in definitions (MCH_AMIGA, AMIGA, et all to be replaced with __amigaos__) and attribute shortcuts (e.g. no __chip for __attribute__((__chip__))). Workarounds for missing definitions can be added to the build process for existing software or bundled into compatibility frameworks like the SDI headers.

Features like stack extension and position-independent / base-relative code will be worked into the standard GCC framework.

I'd also like to differentiate between hardware ISRs and AmigaOS ISRs, i.e. rte v. rts with cc set (?). I'm not sure if the Geek Gadgets port does that.

[Trev]

Yes, and the Geek Gadgets sources define that in the compiler itself to provide source-level compatibility with other compilers. I don't see any reason to do that in the compiler when it can be done just as easily in a Makefile or header.

Also,    CONSTANT_POOL_BEFORE_FUNCTION didn't do what I thought it did. I'm on the GCC list, hopefully getting pointed in the right direction.

EDIT: And rather humorously, I hit a race condition when making gcc with 'make -j 5 all-gcc' on my Core i7. Builds were much, much faster, but I can't have the process hanging (well, spinning forever, in this case) on me. GCC builds quickly, though. newlib is going to be a pain.

[Trev]

8, 16, and 32 bit rotates in gcc 4.4.0:

Code: [Select]


static inline unsigned char _rotl8(unsigned char val, unsigned char shift)
{
    shift &= 7;
    val = (val>>(8 - shift)) | (val << shift);
    return val;
}

static inline unsigned char _rotr8(unsigned char val, unsigned char shift)
{
    shift &= 7;
    val = (val<<(8 - shift)) | (val >> shift);
    return val;
}

static inline unsigned short _rotl16(unsigned short val, unsigned char shift)
{
    shift &= 15;
    val = (val>>(16 - shift)) | (val << shift);
    return val;
}

static inline unsigned short _rotr16(unsigned short val, unsigned char shift)
{
    shift &= 15;
    val = (val<<(16 - shift)) | (val >> shift);
    return val;
}

static inline unsigned long _rotl32(unsigned long val, unsigned char shift)
{
    shift &= 31;
    val = (val>>(32 - shift)) | (val << shift);
    return val;
}

static inline unsigned long _rotr32(unsigned long val, unsigned char shift)
{
    shift &= 31;
    val = (val<<(32 - shift)) | (val >> shift);
    return val;
}


Code: [Select]


volatile unsigned char w = 1;
   c:   1f7c 0001 0027  moveb #1,%sp@(39)

volatile unsigned char a = _rotl8(w, 1);
  12:   102f 0027       moveb %sp@(39),%d0
  16:   0280 0000 00ff  andil #255,%d0
  1c:   2200            movel %d0,%d1
  1e:   d281            addl %d1,%d1
  20:   ee80            asrl #7,%d0
  22:   8001            orb %d1,%d0
  24:   1f40 0026       moveb %d0,%sp@(38)

volatile unsigned char b = _rotr8(w, 1);
  28:   102f 0027       moveb %sp@(39),%d0
  2c:   0280 0000 00ff  andil #255,%d0
  32:   2200            movel %d0,%d1
  34:   e281            asrl #1,%d1
  36:   ef88            lsll #7,%d0
  38:   8001            orb %d1,%d0
  3a:   1f40 0025       moveb %d0,%sp@(37)

volatile unsigned short x = 1;
  3e:   3f7c 0001 0022  movew #1,%sp@(34)

volatile unsigned short c = _rotl16(x, 1);
  44:   302f 0022       movew %sp@(34),%d0
  48:   0280 0000 ffff  andil #65535,%d0
  4e:   2200            movel %d0,%d1
  50:   d281            addl %d1,%d1
  52:   740f            moveq #15,%d2
  54:   e4a0            asrl %d2,%d0
  56:   8041            orw %d1,%d0
  58:   3f40 0020       movew %d0,%sp@(32)

volatile unsigned short d = _rotr16(x, 1);
  5c:   302f 0022       movew %sp@(34),%d0
  60:   0280 0000 ffff  andil #65535,%d0
  66:   2200            movel %d0,%d1
  68:   e281            asrl #1,%d1
  6a:   e5a8            lsll %d2,%d0
  6c:   8041            orw %d1,%d0
  6e:   3f40 001e       movew %d0,%sp@(30)

volatile unsigned long y = 1;
  72:   7001            moveq #1,%d0
  74:   2f40 001a       movel %d0,%sp@(26)

volatile unsigned long e = _rotl32(y, 1);
  78:   202f 001a       movel %sp@(26),%d0
  7c:   e398            roll #1,%d0
  7e:   2f40 0016       movel %d0,%sp@(22)

volatile unsigned long f = _rotr32(y, 1);
  82:   202f 001a       movel %sp@(26),%d0
  86:   e298            rorl #1,%d0
  88:   2f40 0012       movel %d0,%sp@(18)

volatile unsigned z = 1;
  8c:   7401            moveq #1,%d2
  8e:   2f42 000e       movel %d2,%sp@(14)

volatile unsigned g = _rotl(z, 1);
  92:   202f 000e       movel %sp@(14),%d0
  96:   e398            roll #1,%d0
  98:   2f40 000a       movel %d0,%sp@(10)

volatile unsigned h = _rotr(z, 1);
  9c:   202f 000e       movel %sp@(14),%d0
  a0:   e298            rorl #1,%d0
  a2:   2f40 0006       movel %d0,%sp@(6)


In the nonvolatile world (and in the compile-time templates), these examples are all reduced to integer constants.

[Trev]

Careful, that's almost on-topic

You're right. Seen any good movies lately?

(And there really should be a simple way to get rid of the warning. It really does imply that something is syntactically wrong with the inline assembly.)