public inbox for linux-m68k@lists.linux-m68k.org
 help / color / mirror / Atom feed
From: mike <localgost@gmail.com>
To: debian-68k@lists.debian.org, linux-m68k@vger.kernel.org,
	Gunnar von Boehn <gunnar@greyhound-data.com>,
	Bernd Roesch <nospamname@gmx.de>
Subject: Re: toolchain, was Re: bogl: don't know screen type 1
Date: Sat, 5 Sep 2009 04:17:25 +0200	[thread overview]
Message-ID: <8259f0250909041917k6271180buf59040e607c8a642@mail.gmail.com> (raw)
In-Reply-To: <8259f0250909041857i50333429hc01c814a5e1a4e0f@mail.gmail.com>

*hurm* Well if it is the case that some dev at freescale has assumed
that producing binaries in a certain way that makes sense for the
coldfire series ( which might resemble the original enough to make it
seem sensible )  might explain the slowdown were seeing _across the
line_ ( be it amigaos linux or fuckos).

Bernd Roesch ( now included weather he likes it or not, sorry :) has
also made remarks and comparisons about this. As has the amigaos dev's
of ffmpeg, which has made it bleeding clear in the posts linked to
before

http://www.amiga.org/forums/showthread.php?t=47991&highlight=ffmpeg+slowdown

So no the slowdown from 333,340 to 4xx is not only amigaos, its
clearly visible booting the linux kernel too ... .

2009/9/5 mike <localgost@gmail.com>:
> The thing is, its been proven that gcc produces slower and slower 68k
> binaries, its probably not the linker in binutils at all
> see.
> http://www.amiga.org/forums/showthread.php?p=519318
> and  ( not 100% sure if its the correct thread, but the natami team
> have noticed the issue
> http://www.natami.net/knowledge.php?b=3&note=2&z=9M0ieT
>
> Including Gunnar Von Boehn in this now, cause they've done alot more
> research, and can probably fill in what freescale have, and havent
> done. I suspect they have been tweaking the code for newer "68k's" or
> coldfires, rather than branching it off?
>
> Cheers
> -Spike
>
> 2009/9/5 Stephen R Marenka <stephen@marenka.net>:
>> On Sat, Sep 05, 2009 at 01:43:14AM +1000, Finn Thain wrote:
>>>
>>> On Tue, 1 Sep 2009, Stephen R Marenka wrote:
>>>
>>> > On Tue, Sep 01, 2009 at 12:16:27AM +0200, mike wrote:
>>> > > Btw, i noticed an error
>>> > > http://people.debian.org/~smarenka/d-i/m68k/images/daily/build_nativehd.log
>>> > > E: Couldn't find package libnss-dns-udeb
>>> > > make[2]: *** [stamps/get_udebs-nativehd-stamp] Error 100
>>> > > make[1]: *** [_build] Error 2
>>> > > make: *** [build_nativehd] Error 2
>>> >
>>> > Yep. debian-installer dailies are now *dead* until we get a modern libc
>>> > working.
>>>
>>> I wonder whether there are debian source packages for binutils, gcc and
>>> glibc having TLS/NPTL support for m68k.
>>
>> I'd be surprised if that were the case.
>>
>>> The patches posted to the binutils mailing list are incomplete. The
>>> binutils patch at
>>> http://people.debian.org/~smarenka/m68k/tls/
>>> is broken according to Kolla:
>>> http://lists.debian.org/debian-68k/2009/07/msg00001.html
>>>
>>> But in that post (June 28) Maxim recommends using mainline binutils, and
>>> since then we have HJL binutils-2.19.51.0.14 released, "...based on
>>> binutils 2009 0722 in CVS on sourceware.org..." So I guess I should start
>>> there.
>>>
>>> I understand that the current GCC (4.4) lacks the necessary patches, and
>>> 4.5 is still uncooked (and that's a scary prospect). Can someone confirm
>>> that this is the necessary patch for 4.4:
>>> http://gcc.gnu.org/ml/gcc-patches/2009-05/msg01024.html
>>> Presumably not this one?
>>> http://people.debian.org/~smarenka/m68k/tls/gcc_patch2
>>> (and gcc_patch1 is clearly broken... perhaps it was actually the same
>>> thing before being mangled... Stephen, I don't think this "/tls" directory
>>> is helping any.)
>>
>> Shall I remove it then?
>>
>>> Or perhaps there is a known-good gcc 4.5 snapshot (FWIW, I'd much rather
>>> patch a debian compiler instead, which means 4.4 or preferably older.)
>>
>> It would be wonderful to have debian gcc 4.4 building on m68k. It
>> never has.
>>
>>> As for eglibc, there are a number of branches listed here,
>>> http://www.eglibc.org/repository
>>> The question is, which branch, snapshot or release might meet be suitable?
>>>
>>> With this information, I could attempt to build a toolchain from upstream
>>> sources, or figure out whether or not the debian archive has the necessary
>>> source packages...
>>
>> The life is fast ebbing from debian/m68k as far as I can tell. I'm not
>> sure if there is sufficient energy to revitalize it. I'd be delighted to
>> be proven wrong.
>>
>> Peace,
>>
>> Stephen
>>
>> --
>> Stephen R. Marenka     If life's not fun, you're not doing it right!
>> <stephen@marenka.net>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2009-09-05  2:17 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-31  3:28 bogl: don't know screen type 1 mike
2009-08-31 12:06 ` Stephen R Marenka
2009-08-31 12:58   ` mike
2009-08-31 22:11     ` mike
2009-08-31 22:16       ` mike
2009-09-01 15:17         ` Stephen R Marenka
2009-09-03  1:16           ` mike
2009-09-03  1:22             ` mike
2009-09-03  9:50               ` Maxim Kuvyrkov
2009-09-03 16:41                 ` mike
2009-09-11 20:01               ` Kolbjørn Barmen
2009-09-11 20:25                 ` Geert Uytterhoeven
2009-09-12 10:24                 ` fthain
2009-09-04 15:43           ` toolchain, was " Finn Thain
2009-09-05  1:08             ` Stephen R Marenka
2009-09-05  1:57               ` mike
2009-09-05  2:17                 ` mike [this message]
2009-09-05  7:08               ` Petr Stehlik
2009-09-05  8:49               ` Ingo Jürgensmann
2009-09-06  5:07               ` Finn Thain
2009-09-05 13:31             ` Maxim Kuvyrkov
2009-09-05 16:00               ` mike
2009-09-06 10:00                 ` Finn Thain
2009-09-06  2:37               ` toolchain Finn Thain
2009-09-06 23:09                 ` toolchain Stephen R Marenka
2009-09-06  5:20               ` toolchain Finn Thain
2009-09-08 13:07                 ` toolchain Finn Thain
2009-09-13  3:38               ` toolchain, was Re: bogl: don't know screen type 1 fthain
2009-09-13  5:01                 ` Maxim Kuvyrkov
2009-09-14 10:37                   ` fthain
2009-09-22  5:11                     ` mike
2009-09-22 13:09                       ` benchmarks, was Re: toolchain Finn Thain
2009-09-22 14:51                         ` mike
2009-09-22 15:08                           ` Geert Uytterhoeven
2009-09-28 14:00                       ` toolchain, was Re: bogl: don't know screen type 1 mike
2009-09-28 14:26                         ` debian installation Finn Thain
2009-09-28 14:44                           ` mike
2009-09-29  9:45                             ` mike
2009-09-29 22:23                               ` Rolf Anders

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8259f0250909041917k6271180buf59040e607c8a642@mail.gmail.com \
    --to=localgost@gmail.com \
    --cc=debian-68k@lists.debian.org \
    --cc=gunnar@greyhound-data.com \
    --cc=linux-m68k@vger.kernel.org \
    --cc=nospamname@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox