Bad Mood : Falcon030 'Doom'

All 680x0 related coding posts in this section please.

Moderators: exxos, simonsunnyboy, Mug UK, Zorro 2, Moderator Team

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1512
Joined: Sun Jul 31, 2011 1:11 pm

Re: Bad Mood : Falcon030 'Doom'

Postby Eero Tamminen » Fri Nov 25, 2016 10:59 pm

Information about different builds is in builds.txt / README.builds file, depending on which BadMood zip you got.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3468
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Wed Dec 14, 2016 12:38 am

Preview release of BM v0.36 rebuilt using a new Atari compiler - 'Atari BrownElf' GCC 6.2 which we've been quietly hacking away at for a while.

https://dl.dropboxusercontent.com/u/129 ... _gcc62.zip

You can play with this compiler (and some earlier GCC versions for Atari) on our new m68k godbolt compiler-explorer instance thanks to ggn:

http://brownbot.hopto.org


This BM release is still a W.I.P and there may be issues - some minor tweaks are disabled pending a bit more work. The HW MIDI support has also been temporarily removed until I can rebuild Saulot's AMIDILIB library in ELF format. If your default.cfg file has HW MIDI enabled it should be switched off or you may get problems. Software/Codec music is still functional as its part of the main BM sourcecode.


Disclaimer: This involves rebuilt MiNTlib and other stuff for different 680x0 architectures and I haven't been able to test them all properly thus far. Some of the .ttp's may therefore not work properly.

mikro
Atari God
Atari God
Posts: 1263
Joined: Sat Sep 10, 2005 11:11 am
Location: Brisbane, Queensland, Australia
Contact:

Re: Bad Mood : Falcon030 'Doom'

Postby mikro » Wed Dec 14, 2016 2:09 am

Whoa, this needs more explanation! :) I don't know what I'm more excited about, new BM or new GCC :) Can you tell us more about the gcc setup? Apart from "default" Vincent's gcc I know the Peylow's one, it uses registers instead of the stack but who or what "Atari BrownElf" is, I have no clue. :-P

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3468
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Wed Dec 14, 2016 10:37 am

Hi!

mikro wrote:Whoa, this needs more explanation! :) I don't know what I'm more excited about, new BM or new GCC :) Can you tell us more about the gcc setup? Apart from "default" Vincent's gcc I know the Peylow's one, it uses registers instead of the stack but who or what "Atari BrownElf" is, I have no clue. :-P


Well GCC 6.2 is something ggn has been working on for a while with some patience (!) - it's his project really. The initial idea was to take Vincent's patches and apply them to the latest GCC but that didn't work out so well. Important stuff has been dropped or changed after 4.7-ish affecting object formats. So the next idea was to produce m68k ELF output (which is still supported) and convert that to TOS. Turns out someone had already made a .py/linker script for that using v6.0 - which works for some projects but caused problems with more complicated stuff - or any C++ projects, including my own. So we started on a standalone convertor tool we could maintain and which should work with bigger projects - MiNTlib, C++ stuff and so on.

My input has mostly been in the ELF convertor, static initialisation/cleanup for C++, some of the patches needed to get libstdc++ & MiNTlib built & working properly, configuring makefiles & testing with my own projects.

It's still a WIP but works well enough now I'll probably switch over to 6.2 for any new releases.

Vincent's GCC and Peylow's mod are also available via the compiler-explorer linked above, to allow codegen to be compared if anyone ever needs it.

mikro
Atari God
Atari God
Posts: 1263
Joined: Sat Sep 10, 2005 11:11 am
Location: Brisbane, Queensland, Australia
Contact:

Re: Bad Mood : Falcon030 'Doom'

Postby mikro » Wed Dec 14, 2016 11:43 am

Ah, you mean Armin's conversion tool/patches? https://github.com/ardi69/m68k-atari-mint-elf ... anyway, if you have something ready to publish, please do let us know, I'm pretty sure many developers will enjoy it! :)

Now I just wish someone brave enough take a look at gdb, that's a whole different story, I guess you can't cheat there like this. :)

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3468
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Wed Dec 14, 2016 12:31 pm

Actually no - that appears to be yet another one. Didn't know about it at all :-D And it looks more like ours than the .py/ldscript version I mentioned. Still the startup handling seems to be closer to gcc 4.6 than 6.x.

gdb - no that's a harder problem. We do export extended symbols though for use in TOS debuggers, and C++ symbols are also demangled first.

User avatar
mfro
Atari Super Hero
Atari Super Hero
Posts: 663
Joined: Thu Aug 02, 2012 10:33 am
Location: SW Germany

Re: Bad Mood : Falcon030 'Doom'

Postby mfro » Thu Dec 15, 2016 6:41 am

dml wrote:The initial idea was to take Vincent's patches and apply them to the latest GCC but that didn't work out so well. Important stuff has been dropped or changed after 4.7-ish affecting object formats. So the next idea was to produce m68k ELF output (which is still supported) and convert that to TOS. Turns out someone had already made a .py/linker script for that using v6.0 - which works for some projects but caused problems with more complicated stuff - or any C++ projects, including my own. So we started on a standalone convertor tool we could maintain and which should work with bigger projects - MiNTlib, C++ stuff and so on.

Great initiative! Thanks for sharing.

Looked into that as well a while ago and came to the conclusion that you basically only need to fiddle with the linker part (binutils) and startup code to convert ELF output to ATARI compatible relocatable binaries. Did you have to do anything to the compiler itself?

Would require rebuilding all libs, however (but I assume that is the case with your 'afterburner' as well?

Did you look into link time optimization (LTO) support? I'd assume that the most beneficial gain of newer gcc/ELF versions.

Played a little with the compiler-explorer as well and noticed that it appears you have removed/disabled ColdFire support? May I ask to make that available again once you approach something like a final version? Would be nice.

User avatar
willy
Atari nerd
Atari nerd
Posts: 45
Joined: Fri Apr 05, 2013 2:38 pm

Re: Bad Mood : Falcon030 'Doom'

Postby willy » Thu Dec 15, 2016 7:29 am

Hi.

I can see that the new compiler has hardcoded a return function. If the function does not return ANY value, it uses NOP instead.

Code: Select all

int foo(int *num) {
  * num++;
//  return (0);
}

int main () {
int a=2;
  foo(&a);
  return(0);
}


Ataribrown:

Code: Select all

foo(int*):
        link.w %fp,#0
        addq.l #4,8(%fp)
        nop                                    <---- NOP
        unlk %fp
        rts
main:
        link.w %fp,#-4
        moveq #2,%d0
        move.l %d0,-4(%fp)
        move.l %fp,%d0
        subq.l #4,%d0
        move.l %d0,-(%sp)
        jsr foo(int*)
        addq.l #4,%sp
        moveq #0,%d0
        unlk %fp
        rts


Vincent's:

Code: Select all

__Z3fooPi:
        link.w %fp,#0
        addq.l #4,8(%fp)
        unlk %fp
        rts
        link.w %fp,#-4
        jsr ___main
        moveq #2,%d0
        move.l %d0,-4(%fp)
        move.l %fp,%d0
        subq.l #4,%d0
        move.l %d0,-(%sp)
        jsr __Z3fooPi
        addq.l #4,%sp
        moveq #0,%d0
        unlk %fp
        rts



W.

User avatar
mfro
Atari Super Hero
Atari Super Hero
Posts: 663
Joined: Thu Aug 02, 2012 10:33 am
Location: SW Germany

Re: Bad Mood : Falcon030 'Doom'

Postby mfro » Thu Dec 15, 2016 7:48 am

willy wrote:Hi.

I can see that the new compiler has hardcoded a return function. If the function does not return ANY value, it uses NOP instead.


Try adding -O2 to the compiler options and the generated code will start to make a lot more sense.

Strictly speaking, however, the compiler is totally right inserting a nop there. It could even insert complex code formatting your hard drive or send your credit card number to Russia since not returning a value from a non-void function is considered undefined behaviour according to the C standard.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3468
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Thu Dec 15, 2016 11:15 am

mfro wrote:Looked into that as well a while ago and came to the conclusion that you basically only need to fiddle with the linker part (binutils) and startup code to convert ELF output to ATARI compatible relocatable binaries. Did you have to do anything to the compiler itself?


No - it's really only the libs which get patched. The executable is emitted as a normal m68k ELF and then converted using our c++ based tool.

mfro wrote:Would require rebuilding all libs, however (but I assume that is the case with your 'afterburner' as well?


We did have to rebuild the libs yes, for the various targets. This is painful because most of the provided multilib targets are weird coldfire variants which suck up most of the (enormous) build time and some important 68k variants are missing. It's also not easy to change the pattern. We've sorted some of this but some cases still need added.

mfro wrote:Did you look into link time optimization (LTO) support? I'd assume that the most beneficial gain of newer gcc/ELF versions.


As mentioned above, LTO now works fine.
[EDIT]
Sorry correction - I actually posted that info somewhere else. So 'Yes - LTO now works fine' :D

mfro wrote:Played a little with the compiler-explorer as well and noticed that it appears you have removed/disabled ColdFire support? May I ask to make that available again once you approach something like a final version? Would be nice.


Actually we haven't removed it - but the gnu people may have deprecated the alias. They do keep dropping and hiding things. Try passing -mcpu=5474 (and optionally -march=) instead of -m5475 (for example). However YMMV - we don't have coldfire machines ourselves so there's no telling what may fall out of gcc6.2.

[EDIT]
BTW this seems to work too: '-mcfv4e'

User avatar
mfro
Atari Super Hero
Atari Super Hero
Posts: 663
Joined: Thu Aug 02, 2012 10:33 am
Location: SW Germany

Re: Bad Mood : Falcon030 'Doom'

Postby mfro » Thu Dec 15, 2016 11:57 am

dml wrote:... Try passing -mcpu=5474 (and optionally -march=) instead of -m5475 (for example). However YMMV - we don't have coldfire machines ourselves so there's no telling what may fall out of gcc6.2. ...


That's actually what I tested yesterday (-mcfv4e as well but that one is the deprecated option AFAIK) and the compiler didn't cough on it, but nevertheless still generated ror.w instructions (that aren't available on ColdFires), i.e.

Code: Select all

unsigned short bswpw(unsigned short w) {
    return (w << 8) | (w >> 8);
}


still translated to

Code: Select all

        move.l 4(%sp),%d0
        ror.w #8,%d0
        rts


. Which is a step forward for 68000 since this optimization isn't done with Vincent's version but obviously bad for ColdFire since it doesn't run. I have m68k-elf-gcc-6.1 running here and it's doing the right thing (rotate for m68k and two shifts for ColdFire).

dml wrote:This is painful because most of the provided multilib targets are weird coldfire variants which suck up most of the (enormous) build time and some important 68k variants are missing.

You are compiling gcc on Cygwin, do you? I have found Cygwin extremely slow for development, it took ages to build the compiler.
Just did a fresh checkout and compiled m68k-elf-gcc-6.2 from scratch on my Linux box:

Code: Select all

real   2m28.091s


which I don't consider that bad for a package of this complexity.
Last edited by mfro on Thu Dec 15, 2016 4:22 pm, edited 1 time in total.

User avatar
willy
Atari nerd
Atari nerd
Posts: 45
Joined: Fri Apr 05, 2013 2:38 pm

Re: Bad Mood : Falcon030 'Doom'

Postby willy » Thu Dec 15, 2016 4:14 pm

mfro wrote:Try adding -O2 to the compiler options

:)


mfro wrote:Strictly speaking, however, the compiler is totally right inserting a nop there. It could even insert complex code formatting your hard drive or send your credit card number to Russia since not returning a value from a non-void function is considered undefined behaviour according to the C standard.


You are right, but replacing it with void doesnt change anything :)

Please don't consider i think it's something wrong.
It seems to be a native behawior of gcc 5+ on all platforms. It could be used fx for debugging.

W.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3468
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Thu Dec 15, 2016 4:16 pm

mfro wrote:. Which is a step forward for 68000 since this optimization isn't done with Vincent's version but obviously bad for ColdFire since it doesn't run. I have m68k-elf-gcc-6.1 running here and it's doing the right thing (rotate for m68k and two shifts for ColdFire).


That is odd. And something I don't think we can provide an answer for right now. It could be a regression in GCC 6.2 or an innocuous difference or fault in the cross configuration. Unknown at this time - maybe a reason will surface later on with more eyes applied!

User avatar
mfro
Atari Super Hero
Atari Super Hero
Posts: 663
Joined: Thu Aug 02, 2012 10:33 am
Location: SW Germany

Re: Bad Mood : Falcon030 'Doom'

Postby mfro » Thu Dec 15, 2016 4:25 pm

dml wrote:
mfro wrote:. Which is a step forward for 68000 since this optimization isn't done with Vincent's version but obviously bad for ColdFire since it doesn't run. I have m68k-elf-gcc-6.1 running here and it's doing the right thing (rotate for m68k and two shifts for ColdFire).


That is odd. And something I don't think we can provide an answer for right now. It could be a regression in GCC 6.2 or an innocuous difference or fault in the cross configuration. Unknown at this time - maybe a reason will surface later on with more eyes applied!


Just tested on my newly built m68k-elf-gcc-6.2 and it also creates valid (although not necessarily properly optimized) ColdFire code with the above example (so it's not gcc's fault).

Maybe there is simply a problem with the web frontend?

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3468
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Thu Dec 15, 2016 4:29 pm

mfro wrote:Maybe there is simply a problem with the web frontend?


Well that narrows things down a bit. And yes, that is possible. I did see my local instance of godbolt producing 000/020 code differences when switching the CPU but not retested that with the new hosted version. i.e. it could be spitting out 68000 no matter what CPU is given. Although it does error if an invalid CPU arg is passed...

Anyway, it's early days for most of this stuff so hopefully time will tell...

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3468
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Thu Dec 15, 2016 5:29 pm

Aaaaand it was a bug in the bot config. ggn has found and fix0red it.

Was indeed producing 68000 all the time even with -m68020. And it seems to produce coldfire ops again.

\o/

User avatar
mfro
Atari Super Hero
Atari Super Hero
Posts: 663
Joined: Thu Aug 02, 2012 10:33 am
Location: SW Germany

Re: Bad Mood : Falcon030 'Doom'

Postby mfro » Thu Dec 15, 2016 5:55 pm

dml wrote:Aaaaand it was a bug in the bot config. ggn has found and fix0red it.

Was indeed producing 68000 all the time even with -m68020. And it seems to produce coldfire ops again.

\o/


Yes, looks good now.
That front end is a nice toy, thank you both!

User avatar
viking272
Captain Atari
Captain Atari
Posts: 239
Joined: Mon Oct 13, 2008 12:50 pm
Location: west of London, UK

Re: Bad Mood : Falcon030 'Doom'

Postby viking272 » Mon Dec 19, 2016 11:45 pm

Eero Tamminen wrote:Is the devilsdoorbell site nowadays OK?

Few months ago when I went there, the address was pwned by something else. When I (just now) visited it with w3m browser, it looked OK, but maybe that's just because some exploit code didn't recognize my text-only www-browser... :-)

As the site owner I wasn't aware of this!!
The site looks OK and hopefully I can check things out of Xmas when I have some time.

Good to see some more life in this project :D

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1512
Joined: Sun Jul 31, 2011 1:11 pm

Re: Bad Mood : Falcon030 'Doom'

Postby Eero Tamminen » Sat Dec 31, 2016 5:39 pm

I finally had time to check the new GCC 6.2 BadMood build.

Initially I started with earlier BM cache, but apparently BM didn't like that as it froze when it started to automatically update it. When starting from known good cache content, the cache update ("-bmup" BM option) worked.

When the cache update didn't work, I noticed that after ~830 lumps, BM starts to try to access non-existing HD patches (starting from "hd\patch\_GDOOR.bmp", and lastly trying to access "hd\patch\LITEMET.bmp" at lump 921).

Are those missing HD patches still relevant, and if yes, is there an updated HD patchset available?

With Hatari 2.0 default WinUAE CPU core, Hatari's Falcon emulation is too slow for my machine (frame skip is constantly at max and music sounds bad). Happily BM (bmhat.ttp at least) works also with Hatari's oldUAE CPU core, which is faster (although its emulation is less accurate), fast enough on my machine that music sounds fine and there's no frame skipping. With that, BM works great!

I noticed few minor issue:
* Statusbar doesn't anymore work even with bmhat.ttp and when NatFeats is enabled.
*At the end of Deimos Anomaly, there's a really long pause until the finished screen comes up, but there's no disk icon visible.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3468
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Tue Jan 03, 2017 7:44 pm

Hi Eero,

I think the cache update problem is actually a bug in the engine - probably recent. Haven't really had time to look for it yet but I've made a note. It's been reported by 2 other people and therefore 'consistent'. Maybe I've done something that requires those extra patch textures, when they're supposed to be optional... well at least it works with the prebaked BMC .zip.

Hatari 2.0 is trying to emulate the DSP as 64mhz, so this pretty much sinks the host thread for any task using the DSP at high duty. OTOH it does improve compatibility a great deal re: CPU/DSP sync issues - i can run builds without special hatari-safe options now without running into trouble :D Still the cost of emulating a 64mhz DSP is quite extreme. My 3ghz i7 struggles with Q2 and '030'.

I wonder if the new vs old core is indirectly changing the DSP duty?

The status bar thing is my fault - i forgot to configure some flags to manage the SB specially for hatari. As for the 'long pause' - no idea :)

BTW I've noticed some problems reading symbols from our gcc6 executables in Hatari debugger. It looks like its trying, then gives up with some errors. This is in GST extended mode. In the normal 8-char symbol mode, it is successful but im still not sure its working correctly because I can page down through tons of disasm without seeing any labels - but few obvious labels like _main are in the right place. Maybe the gcc6/tos side has a bug somewhere, although it seems to work correctly in the label-aware version of STEEM.

Sorry this is a bit random - not able to investigate these things properly just now. But I'll perhaps forward something concrete later.

Cheers

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1512
Joined: Sun Jul 31, 2011 1:11 pm

Re: Bad Mood : Falcon030 'Doom'

Postby Eero Tamminen » Tue Jan 03, 2017 10:09 pm

dml wrote:I wonder if the new vs old core is indirectly changing the DSP duty?


It doesn't emulate cache at all, so its balance is quite different.

When I run "CenTurbo benchmark", it gave different Hatari versions, and CPU cores quite different speeds:

Code: Select all

2.0, WinUAE CPU core:
* FPU: 920 MHz
* DSP: 64 MHz
* CPU: 27 MHz

2.0, oldUAE CPU core:
* FPU: 403 MHz
* DSP: 62 MHz
* CPU: 78 MHz

1.9, WinUAE CPU core:
* FPU: 812 MHz
* DSP: 56 MHz
* CPU: 27 MHz

1.9 & 1.8, oldUAE CPU core:
* FPU: 403 MHz
* DSP: 32 MHz
* CPU: 78 MHz


According to that, FPU speed is even more distorted compared to CPU speed than DSP...


dml wrote:The status bar thing is my fault - i forgot to configure some flags to manage the SB specially for hatari. As for the 'long pause' - no idea :)


I noticed the pause too late, to be able to do any tracing or profiling. Is it possible that it's doing disk access, but just for some reason isn't showing disk icon?


dml wrote:BTW I've noticed some problems reading symbols from our gcc6 executables in Hatari debugger. It looks like its trying, then gives up with some errors. This is in GST extended mode. In the normal 8-char symbol mode, it is successful but im still not sure its working correctly because I can page down through tons of disasm without seeing any labels - but few obvious labels like _main are in the right place. Maybe the gcc6/tos side has a bug somewhere, although it seems to work correctly in the label-aware version of STEEM.


Do you know whether STEEM supports anything extra besides GST extended mode?

If you can send the binary to me, I could check whether I notice anything obvious to fix in my symbol parsing code.


dml wrote:Sorry this is a bit random - not able to investigate these things properly just now.


Sure, not problem, this all is just FYI. We do this for fun, when and *if* we have time. I appreciate anything you have time to do and hope you keep in good health!

(I though to just quickly check BM, and ended up playing through several levels until I eventually died... So everything worked fine and statusbar missing didn't add that much extra difficulty. :))

User avatar
Cyprian
Atari God
Atari God
Posts: 1398
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Re: Bad Mood : Falcon030 'Doom'

Postby Cyprian » Tue Jan 03, 2017 10:28 pm

dml wrote:although it seems to work correctly in the label-aware version of STEEM.

do you mean steem debuger with the labels support?
Jaugar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
SDrive / PAK68/3 / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Aranym / Steem / Saint
http://260ste.appspot.com/

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3468
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Tue Jan 03, 2017 10:34 pm

Cyprian wrote:
dml wrote:although it seems to work correctly in the label-aware version of STEEM.

do you mean steem debuger with the labels support?


Yes - that one. :)

User avatar
Cyprian
Atari God
Atari God
Posts: 1398
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Re: Bad Mood : Falcon030 'Doom'

Postby Cyprian » Tue Jan 03, 2017 11:44 pm

great. I've just checked Steem.SSE.3.9.0.Win32.Debug.zip from SF and I've checked my test program and I can't see any label. Is it correct version or should I tick an option somewhere?
Jaugar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
SDrive / PAK68/3 / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Aranym / Steem / Saint
http://260ste.appspot.com/

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3468
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Tue Jan 03, 2017 11:52 pm

Cyprian wrote:great. I've just checked Steem.SSE.3.9.0.Win32.Debug.zip from SF and I've checked my test program and I can't see any label. Is it correct version or should I tick an option somewhere?


The one I'm talking about is Mr Pink's fork - labels aren't supported in SSE as far as I know. Sorry I should have been a bit more specific!


Social Media

     

Return to “680x0”

Who is online

Users browsing this forum: No registered users and 4 guests