Re: [Freemint-discuss] [Freemint-list] Broken udelay() for m68000

[Miro K. <mir...@gm...>]

Hi David,

if the interpretation you've mentioned in https://github.com/
freemint/freemint/issues/70 holds for all drivers (i.e. that the delay is
supposed to wait *at least* X microseconds) there shouldn't be any
regressions IMHO -- the new formula must definitely take longer than the
previous stub.

As for your question
<https://github.com/freemint/freemint/issues/70#issuecomment-366506935> about
"__M68020__": gcc 7.2 emits them only for -m68020-40 and -m68020-60 (no,
not even -m68020!). It definitely seems like some kind of deprecated macro
kept only for the minimal backward compatibility.

On 19 February 2018 at 02:32, David Gálvez <dga...@gm...> wrote:

> Yesterday I sent the email below to the list address at atari-forge, I
> didn't watch that the email I was answering was sent to the the old
> list address.
> Today it bounced so I send it again to the right address.
>
> 2018-02-17 10:04 GMT+01:00 David Gálvez <dga...@gm...>:
> > 2017-10-16 3:57 GMT+02:00 Miro Kropáček <mir...@gm...>:
> >> After some study, it seems it isn't that bad (I think most of you were
> aware
> >> of it): the delay functions are calibrated, quite precisely actually.
> That
> >> loops_per_sec variable is actually a result of such calibration.
> >>
> >> So the problem is that m68000 code ignores it. I think David is right,
> the
> >> magic formula used in the linux kernel is supposed to work on all
> m68ks, not
> >> only ColdFire (see the comment, "simpler m68k").
> >>
> >> On m68000, the code is quite chatty:
> >>
> >>      3a4:       206a 001c       moveal %a2@(28),%a0
> >>      3a8:       4878 00c8       pea c8 <oldSR-0x1c>
> >>      3ac:       2f10            movel %a0@,%sp@-
> >>      3ae:       4e93            jsr %a3@
> >>      3b0:       508f            addql #8,%sp
> >>      3b2:       720b            moveq #11,%d1
> >>      3b4:       e2a8            lsrl %d1,%d0
> >>      3b6:       2200            movel %d0,%d1
> >>      3b8:       d280            addl %d0,%d1
> >>      3ba:       d280            addl %d0,%d1
> >>      3bc:       2801            movel %d1,%d4
> >>      3be:       e98c            lsll #4,%d4
> >>      3c0:       d284            addl %d4,%d1
> >>      3c2:       2801            movel %d1,%d4
> >>      3c4:       e18c            lsll #8,%d4
> >>      3c6:       d284            addl %d4,%d1
> >>      3c8:       e789            lsll #3,%d1
> >>      3ca:       d081            addl %d1,%d0
> >>      3cc:       ec88            lsrl #6,%d0
> >>
> >> (a3 points to ___udivsi3)
> >>
> >> However we should use this code also for 68060 and not only for CF as
> mul
> >> ea,dr:dq is not implemented on 060 (leading to a huge performance
> bottleneck
> >> I imagine).
> >>
> >
> > I've just pushed a commit to make 68000 builds to use "real" delays
> > and fix this situation.
> >
> > Some drivers that were adjusted to the old delay method could break,
> > For what I could see they're usb.km, storage.udd and asix.xif or the
> > TOS variant of them (only 68000 builds).
> > I've asked in AF for testers but I didn't get too much feedback, I
> > decided to push anyway I don't want the commits to end dying in my
> > hard drive as already has happened to me in the past.
> > If you read users complaining about these drivers malfunction with
> > recent kernel versions keep in mind this commit could be a reason.
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Freemint-discuss mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freemint-discuss
>



-- 
MiKRO / Mystic Bytes
http://mikro.atari.org