[Freemint-list] Three CPU targets for *everything*

Miro Kropáček miro.kropacek at gmail.com
Sat Feb 11 11:49:53 MSK 2017


>
> My opinion is that such changes is exactly what should be discussed
> here.

... and that's exactly the reason why I'm posting it here. ;-) The link, if
you look closely, is a pull request, i.e. source code for the proposed
change. Which is, on the contrary, very unsuitable for this list. See?
Everything makes perfect sense. :-)

- How have you merged the 040 and 060 builds?
>
Simply (it's in the pull request, btw :-)), changed "#if defined (M68040)
&& defined (M68060)" to "#ifdef M68040". Except one line, this is all what
040/060 kernel was about and yes, it was me who did it years ago.

- Why is the 040 build considered useless?
>
Ah, OK. There's the AB040, sorry. I will add it to the KERNELDEF's comment.


> - The Milan has a separate kernel for a reason. How are Milan features
> detected now?
>
They are not. There's still mintmil.prg


> - How does the new build targets actually work? Are there less kernels
> but with code to autodetect features (e.g. Milan), or is the number of
> kernels the same but mintloader takes care of selecting which one to
> load?
>
Milan see above, the rest - yes. mintloader decides whether to load
min4060.prg, mintara.prg or mintmil.prg. For mint000.prg and mint030.prg
there's no need for mintloader but it will make things much cleaner in my
forthcoming work.

- How does mintloader load the correct modules depending on
> architecture?
>
It doesn't, mint???.prg does. You perhaps don't remember my work on mchdir
a couple of years ago. :)


> - What does this do to kernel- and distribution sizes? Memory
> consumption?
>
Nothing. Only "harm" is that you wont get your CT60 kernel optimised with
-m68060 but with -m68020-60 instead (and vice versa).

Don't get me wrong, I'm not against changes. But is your implementation
> a suitable one? I have no idea, because I don't know anything about it
> except that it somehow involves mintloader :) Maybe there are better
> solutions? Or maybe this is a really good one? A discussion would have
> highlighted that.
>
I hope it's clearer now, in fact, it's not very significant change. But I'm
pretty sure same as I was a strong believer in "a cpu optimised kernel for
every possible hardware" 10 years ago, there may be people with the same
opinion now.


-- 
MiKRO / Mystic Bytes
http://mikro.atari.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.atariforge.org/pipermail/freemint-list/attachments/20170211/d65855c2/attachment.html 


More information about the Freemint-list mailing list