| [News] Pre-Realese announcement | ANN.lu |
| Posted on 13-May-2004 20:17 GMT by ece | 227 comments
View flat
View list | |
After consultation with our German CD production partner, House of Audio, Hyperion Entertainment is pleased to announce that the Developer Pre-Release of AmigaOS 4.0 is now tentatively scheduled for May 21th, 2004.
Leuwen, Belgium - May 13 2004.
The AmigaOS 4.0 CD will be distributed through your AmigaOne dealer.
Source: Amigaworld.net
|
|
| Pre-Realese announcement : Comment 201 of 227 | ANN.lu |
| Posted by Stefan Burström on 16-May-2004 20:00 GMT | In reply to Comment 157 (Fabio Alemagna):
>Is that supposed to be fun? No, really, is there some irony in that statement?
What I was trying to explain to you was that it is not sure that the generic solution to a problem is also always the fastest one. Given a moderately sorted array, would you rather use bubble sort on it or quicksort? We both know that quicksort is faster in the general case, but when we have more information at hand, we can actually make use of that information for our own purposes.
>because yours is twofold. A claim without validity, and I can easily prove it: look at MOS' emulator.
Fabio, you have no clue what you are talking about. A generic m68k mui custom class does not have any emulator traps built into it, therefore the code what is accessing it has to create the emulator trap or in some other way make sure to start the m68k emulator on the loaded class. There is no way you can just set up an exception in the m68k code because the exception will never know the ppc->m68k register mappings.
>Everybody knows because that's what we've been told, as I showed above. We've, >in more than one occasion, been told that the emulator works that way.
Well, I have been reading alot of things here and that is something I have never been told. You are mixing things up here.
>Sorry? What would be childish in what I'm saying? I'm commenting on the way >AOS4 emulates 68k code, is that forbidden? Can't you stand criticism?
You lost the pointer here. I was talking about how m68k code can be invoked, and not how it is emulated. And there are several ways m68k code can be invoked and they all have to be handled.
> Besides, I was giving you a rather technical
> explanation since I don't want to get in the 'no, you are wrong, I am right'
> type of discussion. And I was hoping that you (and others) would take the
> opportuinity to learn something, but apparently you are not receptive to
> that.
>Please, enlighten me on this "something" I had the opportunity to learn. You >are assuming that the fact you went into technical details would make me shut >up, perhaps because you think that the AOS4 solution is the best possible one,
No, I was making it rather techincal in an attempt to keep the discussion on a techical level instead of getting into the usual 'I am right, you are wrong argument' So far you have never presented a single argument that proves your point. All you have said is that MOS solves this or that problem more efficient so OS4 must be bad. But you have never provided an explanation on how MOS solves it which makes me think that you never unstood (or bothered to understand) the problem in the first place.
>but I am even more convinced, now that you went into techincal details, that it's perhaps the worse one: having the need to manually call Emulate() to avoid performance penalties, when this need is unexistent on alternative emulators, seems clumsy and certainly not the best solution.
If you think this is unexisting in MOS, you need to do your homework again. There is no way a generic solution can handle this since it cannot handle ppc->m68k register transfers since the ABI of a generic m68k function is not known by the emulator.
>Perhaps who should learn something is <n>not me here. By the way, You should also learn how to discuss without resorting to denigrating the other party when you feel cornered.
I don't know in what way I should feel cornered. But the fact is that the way you acted in this discussion is exactly the same way you have reacted in alot of other discussions here whenever you felt someone was wrong. And that is why I treat you the way I do. Your reputation precedes you and that is not my fault!
regards,
Stefan Burström |
|
| Pre-Realese announcement : Comment 202 of 227 | ANN.lu |
| Posted by naked on 16-May-2004 21:11 GMT | | you people taught me madness... that is what i ~~~~~~~~~~~~~~~~~ rogntudjuuuu |
|
| Pre-Realese announcement : Comment 203 of 227 | ANN.lu |
| Posted by Fabio Alemagna on 17-May-2004 09:24 GMT | In reply to Comment 201 (Stefan Burström):
> What I was trying to explain to you was that it is not sure that the generic
> solution to a problem is also always the fastest one. Given a moderately
> sorted array, would you rather use bubble sort on it or quicksort? We both
> know that quicksort is faster in the general case, but when we have more
> information at hand, we can actually make use of that information for our
> own purposes.
Nice try, but that's not what you said. Had you said that, I would have had nothing to argue about, since it's pretty obvious that a "better solution is a better solution", it's a tauthology, d'oh!
However, you said that AOS4 is the best possible solution, regardless of whether some other systems use a different solution that works just fine and is simpler than yours, and more speed-effective.
You really make no sense, sorry.
>> because yours is twofold. A claim without validity, and I can easily prove
>> it: look at MOS' emulator.
> Fabio, you have no clue what you are talking about.
:-) You're funny :)
> A generic m68k mui custom
> class does not have any emulator traps built into it, therefore the code
> what is accessing it has to create the emulator trap or in some other way
> make sure to start the m68k emulator on the loaded class. There is no way
> you can just set up an exception in the m68k code because the exception will
> never know the ppc->m68k register mappings.
Ok, let me explain a few facts to you.
1) Regardless of what you say, yes, AmigaOS4's emulator worked and to some extents (at least by reading what you are writing) works also now, but only as a "fall back", slow, solution, by intercepting, via MMU, attempts at executing data.
amigaworld.net is full of posts by Rogue and company where this fact is both hinted and explicitely said. Unfortunately, the search engine sucks a bit, so all I could find, until Georg Steget replies to the email I sent him on the subject, is this:
http://amigaworld.net/modules/newbb/viewtopic.php?mode=viewtopic&topic_id=555&forum=4&start=20&viewmode=flat&order=0
Quote:
Reserve a big chunk of virtual address space for loadseg'd68k code?
Actually, it's the other way round. There's a virtual segment for PPC code. The PPC can only grant execute permission on a per-segment basis. So one or more segments have execute permission.
That's just an hint, but feel free to browse amigaworld.net yourself for more evidence. If you still don't want to believe me, well, what can I do, I know I'm telling the truth.
2) Now, you say, you have the option to call the "Emulate()" function. Notice: option. In MOS that's not an option, that's the rule, except that applying such a rule is completely transparent to the programmer, who never has to really care about what's going on and when to trigger the emulator on and off. This is not the place to go into further details, and MOS developers, if they want, will enlighten you more than I ever could, but suffice to say that for the way the emulator works there's never any cpu exception and, by default, there's no context switch, as there's a 1:1 mapping between PPC registers and 68k ones.
What I see is that AOS4 developers finally realized that their solution was, ehm, a bit crappy, and decided to go for the same type of solution MOS uses, except that they kept the old one there, for some reasons unknown to me.
>> Everybody knows because that's what we've been told, as I showed above.
>> We've,
>> in more than one occasion, been told that the emulator works that
>> way.
> Well, I have been reading alot of things here and that is something I have
> never been told. You are mixing things up here.
Of course, it can't be that you are wrong, it must be me :-) Anyway, as said, it's your loss, not mine. As soon as I get the answer to that email, I'll show you the place(s) where they said it.
You might also want to ask them directly: they will surely not lie to you.
> > Sorry? What would be childish in what I'm saying? I'm commenting on the
> > way AOS4 emulates 68k code, is that forbidden? Can't you stand criticism?
> You lost the pointer here. I was talking about how m68k code can be invoked,
> and not how it is emulated. And there are several ways m68k code can be
> invoked and they all have to be handled.
And I commented on those ways. And you said I was acting childishly. So, I reask: what's childish in what I said?
> No, I was making it rather techincal in an attempt to keep the discussion on
> a techical level instead of getting into the usual 'I am right, you are
> wrong argument' So far you have never presented a single argument that
> proves your point.
Well, I've pointed you to a "live" proof: MOS. You refused to accept it. Now I've explained something more for you. Let's see if you'll accept it, but somehow I doubt it.
> All you have said is that MOS solves this or that problem more efficient so
> OS4 must be bad.
> But you have never provided an explanation on how MOS solves it which makes
> me think that you never unstood (or bothered to understand) the problem in
> the first place.
I didn't need to tell you how MOS worked to make the point I was making: MOS is more efficient, in this regard, thus it's proven that MOS solution is better. If you want to know why it's more efficient, well, I've explained it to you above.
> If you think this is unexisting in MOS, you need to do your homework again.
So, you don't know how MOS works, by your implicit admission, yet you pretend you know that it can't do things in any other way than AOS4 does?
Anyway, I explained to you above how it works.
> There is no way a generic solution can handle this since it cannot handle
> ppc->m68k register transfers since the ABI of a generic m68k function is not
> known by the emulator.
What I don't understand about you is how can you make so bold statement...? 68k library functions take parameters into registers; there's a finite number of these registers ==> you can create a 1:1 mapping between ppc registers and 68k registers or between some memory location and 68k registers, so you don't need to know the ABI of the generic m68k function, all you need to do is set up register properly, or have them already set up.
> I don't know in what way I should feel cornered. But the fact is that the
> way you acted in this discussion is exactly the same way you have reacted in
> alot of other discussions here whenever you felt someone was wrong. And that
> is why I treat you the way I do. Your reputation precedes you and that is
> not my fault!
As long as I can see, you are still wrong, despite all your whining. Now, go on believing whatever you want, it's out of my concern. |
|
| Pre-Realese announcement : Comment 204 of 227 | ANN.lu |
| Posted by Fabio Alemagna on 17-May-2004 09:32 GMT | In reply to Comment 203 (Fabio Alemagna):
An addendum to my post, to further prove the point that the AOS4 emulator works (or can work, or mostly works, take your pick) by interpreting ppc data as m68k code.
I'm sorry, the formatting will come out quite wrong, try to make your best to get anything meaningful from the below code:
/*
** This file was automatically generated by fdtrans.
** Do not edit it by hand. Instead, edit the sfd file
** that was used to generate this file
*/
#include "exec/interfaces.i"
#include "exec/libraries.i"
#include "exec/emulation.i"
#include "mpega.i"
/* -------------------- Open ---------------------------*/
.section .data
.globl stub_Open
.type stub_Open, @function
stub_Open:
.short 0x4ef8 /* JMP.w */
.short 0 /* Indicate switch */
.short 1 /* Trap type */
.globl stub_OpenPPC
.long stub_OpenPPC
/* Register mapping */
.byte 2
.byte 1,REG68K_A7
.byte 3,REG68K_A6 |
|
| Pre-Realese announcement : Comment 205 of 227 | ANN.lu |
| Posted by Stefan Burström on 17-May-2004 11:44 GMT | In reply to Comment 203 (Fabio Alemagna):
>Nice try, but that's not what you said. Had you said that, I would have had nothing to argue about, since it's pretty obvious that a "better solution is a better solution", it's a tauthology, d'oh!
That was the point I was trying to bring across, but you are so damn stubborn that you are refusing to understand what I am writing instead of trying to shove your oppinion into other peoples faces!
>However, you said that AOS4 is the best possible solution, regardless of whether some other systems use a different solution that works just fine and is simpler than yours, and more speed-effective.
No, I didn't say that the AOS4 solution was the best possible solution. All I said was that you are wrong making the generic assumption that a generic solution is always better than a two fold.
>You really make no sense, sorry.
Perhaps becuase yuo never bothered to read what I wrote? Sorry, but this is not the first time you have made that mistake.
> Fabio, you have no clue what you are talking about.
:-) You're funny :)
> A generic m68k mui custom
> class does not have any emulator traps built into it, therefore the code
> what is accessing it has to create the emulator trap or in some other way
> make sure to start the m68k emulator on the loaded class. There is no way
> you can just set up an exception in the m68k code because the exception will
> never know the ppc->m68k register mappings.
>Ok, let me explain a few facts to you.
See my comment below and rething your facts...
1) Regardless of what you say, yes, AmigaOS4's emulator worked and to some extents (at least by reading what you are writing) works also now, but only as a "fall back", slow, solution, by intercepting, via MMU, attempts at executing data.
That is the plan for Petunia, yes, but that is only to help when you are emulating ppc converted m68k code that still refers to some non converted code.
Believe me or not but there _is no transparent way to bridge between generic PPC code and m68k code_ since the ABI's are different. Ask some of the MOS developers and I am sure they can explain to you how it works.
>2) Now, you say, you have the option to call the "Emulate()" function. Notice: option. In MOS that's not an option, that's the rule, except that applying such a rule is completely transparent to the programmer, who never has to really care about what's going on and when to trigger the emulator on and off. This is not the place to go into further details, and MOS developers, if they want, will enlighten you more than I ever could, but suffice to say that for the way the emulator works there's never any cpu exception and, by default, there's no context switch, as there's a 1:1 mapping between PPC registers and 68k ones.
1:1 mapping between PPC registers and m68k registers will get you nowhere if you don't know the ABI of a function. I was trying to tell you that, but apparently you never saw that. An m68k library function can be defined with arbitrary register assignments to their parameters whereas the PPC ABI strictly defines that the first parameter should go into r3, the next r4 and so forth.
And there are even amiga os functions that takes more than 8 parameters in
registers whereas the PPC will pass register #9 and so on onto the stack. So, where is your 1:1 mapping leading you now?
>What I see is that AOS4 developers finally realized that their solution was, ehm, a bit crappy, and decided to go for the same type of solution MOS uses, except that they kept the old one there, for some reasons unknown to me.
Well, actually you don't see anything, because you havn't realized the underlying problems. When you do that, we can start to discuss this again
>Of course, it can't be that you are wrong, it must be me :-) Anyway, as said, it's your loss, not mine. As soon as I get the answer to that email, I'll show you the place(s) where they said it.
Well, I have been trying to understand how stuff works instead of beeing to quick judging them to be inefficient, non working or written by bad coders. Which from your track record has been more standard.
>And I commented on those ways. And you said I was acting childishly. So, I reask: what's childish in what I said?
Pointing fingers was childish. When I told you that you were wrong, you were pretty quick to say that it wasn't you who stated the facts. You were just repeating what you thought was common knowledge. But you never bothered to check the facts and to realize what the common knowledge actually was.
>Well, I've pointed you to a "live" proof: MOS. You refused to accept it. Now I've explained something more for you. Let's see if you'll accept it, but somehow I doubt it.
Now, again, explain to me how an generic m68k function can be called from PPC without knowing the ABI. Until you know that, MOS is no proof since they have to have specific solutions for specific libraries in there. Either you don't know it you are just hoping I wont call your bluff.
>I didn't need to tell you how MOS worked to make the point I was making: MOS is more efficient, in this regard, thus it's proven that MOS solution is better. If you want to know why it's more efficient, well, I've explained it to you above.
Since you dont know how neither MOS nor AOS4 works, I doubt that you are entitled to be the one to say which solution is the most efficient. (Hint since you have failed to provide a solution to the API problem, I am assuming that you don't know how it works.)
>So, you don't know how MOS works, by your implicit admission, yet you pretend you know that it can't do things in any other way than AOS4 does?
Well, I know enought about computers and system design to know what's possible and what is not.
>Anyway, I explained to you above how it works.
No, you never explained how MOS is guessing the ABI of the m68k libraries.
>What I don't understand about you is how can you make so bold statement...? 68k library functions take parameters into registers; there's a finite number of these registers ==> you can create a 1:1 mapping between ppc registers and 68k registers or between some memory location and 68k registers, so you don't need to know the ABI of the generic m68k function, all you need to do is set up register properly, or have them already set up.
Well, that was the point I was trying to get across. You need to do this mapping explicitly. No emulator can handle this completely transparent given the ABI used by AmigaOs-m68k
>As long as I can see, you are still wrong, despite all your whining. Now, go on believing whatever you want, it's out of my concern.
Whining? Care to elaborate? Besides, aren't you the one whining left and right about other peoples stupid mistakes and implementations all the time? Time to do some useful things instead of spending all your time in forums pretending to be 'Mr know it all' ? |
|
| Pre-Realese announcement : Comment 206 of 227 | ANN.lu |
| Posted by Georg Steger on 17-May-2004 12:13 GMT | > 1:1 mapping between PPC registers and m68k registers will get you nowhere if you don't know the ABI of a function. I was trying
> to tell you that, but apparently you never saw that. An m68k library function can be defined with arbitrary register assignments to
> their parameters whereas the PPC ABI strictly defines that the first parameter should go into r3, the next r4 and so forth.
> And there are even amiga os functions that takes more than 8 parameters in
> registers whereas the PPC will pass register #9 and so on onto the stack. So, where is your 1:1 mapping leading you now?
PPC library functions are not like any other "normal" PPC function in MorphOS.
Example:
/**
* ObtainInfoA
**/
ULONG LIB_ObtainInfoA(void)
{
FT_GlyphEngine *engine=(FT_GlyphEngine *)REG_A0;
struct TagItem *tags=(struct TagItem *)REG_A1;
struct Library *FTBase=(struct Library *)REG_A6;
[...]
}
<emul/emulregs.h>:
#ifdef EMUL_QUICKMODE
register ULONG REG_D0 __asm("r16");
[...]
register ULONG REG_A0 __asm("r24");
[...]
#else
#define REG_D0 (MyEmulHandle->Dn[0])
[...]
#define REG_A0 (MyEmulHandle->An[0])
[...] |
|
| Pre-Realese announcement : Comment 207 of 227 | ANN.lu |
| Posted by Stefan Burström on 17-May-2004 12:46 GMT | In reply to Comment 206 (Georg Steger):
>PPC library functions are not like any other "normal" PPC function in MorphOS.
Example:
It is just that I was talking about calling m68k libraries from PPC code. Not about making sure that PPC library functions are callable from both ppc and emulated code.
regards,
Stefan |
|
| Pre-Realese announcement : Comment 208 of 227 | ANN.lu |
| Posted by vortexau on 17-May-2004 13:25 GMT | In reply to Comment 195 (Don Cox):
> I don't think Eva is good enough at English to do that.
THAT'S an understatement if I ever comtemplated such a topic!
Even Eliza produces superior English grammar, than does Eva! :-) |
|
| Pre-Realese announcement : Comment 209 of 227 | ANN.lu |
| Posted by Fabio Alemagna on 17-May-2004 13:29 GMT | In reply to Comment 205 (Stefan Burström):
In Reply to Comment 203 (Fabio Alemagna):
>> However, you said that AOS4 is the best possible solution, regardless of
>> whether some other systems use a different solution that works just fine
>> and is simpler than yours, and more speed-effective.
> No, I didn't say that the AOS4 solution was the best possible solution. All
> I said was that you are wrong making the generic assumption that a generic
> solution is always better than a two fold.
For God's sake, when and where have I stated such an absurd thing? Since when saying that one particular onefold solution is better than your twofold solution equals to saying that a generic onefold solution is better than any twofold solutions?!
>> 1) Regardless of what you say, yes, AmigaOS4's emulator worked and to some
>> extents (at least by reading what you are writing) works also now, but only
>> as a "fall back", slow, solution, by intercepting, via MMU, attempts at
>> executing data.
> That is the plan for Petunia, yes, but that is only to help when you are
> emulating ppc converted m68k code that still refers to some non converted
> code.
If plans have changed again, I don't know, but up to a few weeks ago rogue and company kept saying what I said here before, that is ppc data is considered 68k code when the ppc program tries to execute it. I told you to ask them directly: did you?
> Believe me or not but there _is no transparent way to bridge between generic
> PPC code and m68k code_ since the ABI's are different. Ask some of the MOS
> developers and I am sure they can explain to you how it works.
What makes you think I don't talk to MOS developers? I wonder how can you make such bold claims... gee, how can you talk about things you clearly have no clue about?!
Let me explain in a few rows how it works. This is information you could gather yourself, but you prefer talking about hot hair rather than getting informed... anyway:
1) PPC -> PPC trasition is trivial
2) 68k -> 68k transition is trivial
3) PPC -> 68k transition.
In this case the equivalent of your Emulate() function is, transparently, called, and 68k code is executed. 99% of the times, that is as long as the 68k code is accessed via hooks or other similar, standard mechanisms, this fact is completely hidden to the programmer. In the minority of cases, that is when a function pointer, which could be also pointing to a 68k function, is used, then an "emulgate" must be used, but also this is abstrated by a few macros.
4) 68k -> PPC code
This can only ever happen for callbacks, or library functions, and in both cases an "emulgate" has to be created for the target function. The emulator jumps to the gate, not to the function itself, and the emulgate contains an "instruction" to switch the emulator off.
It's that easy, and aside from possible little mistakes I've made in giving you that description (I confide in any of the MOS developers for correcting me) that's how it works. No MMU is involved, no need for strange stubs functions, no need to hardcode in the stub which parameters go in which registers.
> 1:1 mapping between PPC registers and m68k registers will get you nowhere if
> you don't know the ABI of a function. I was trying to tell you that, but
> apparently you never saw that. An m68k library function can be defined with
> arbitrary register assignments to their parameters whereas the PPC ABI
> strictly defines that the first parameter should go into r3, the next r4 and
> so forth.
Thanks for lectuing me on the SYSV ABI (it's not the PPC ABI, it's one PPC ABI), but I already knew all that.
Perhaps there's been a misunderstanding here, so let me take the opportunity to discuss this in a more linear way:
> No, you never explained how MOS is guessing the ABI of the m68k libraries.
The point is: no guesswork is being done. Simply put, the m68k libraries and the PPC ones use the same ABI! Both take parameters into 68k registers. The 68k ones, of course, access the virtual 68k registers transparently, whilst the ppc ones access them explicitely, via something called "emulhandle", a structure holding, among other things, the content of the 68k registers. Such a structure is always kept in r2, thus loading/storing arguments there is basically like loading/storing arguments from the stack, from the point of view of the native PPC function.
Such argument passing is completely hidden to you, both when using those functions and when programming them, as MOS uses the same macros AROS "invented", hence it's all perfectly abstracted and hidden.
Now, is it clear? Will you stop thinking the world is "red"? :-)
> Well, actually you don't see anything, because you havn't realized the
> underlying problems. When you do that, we can start to discuss this again
You really make me smile :-) I can't even get upset, it's just so fun :-)
> Well, I have been trying to understand how stuff works instead of beeing to
> quick judging them to be inefficient, non working or written by bad coders.
> Which from your track record has been more standard.
I said "inefficient", but I've not said "non working" or "bad coders". It's you who are saying it, and this goes to show that you are so full of yourself that attribute to me things I've never said or implied just so that you can make me look like a fool. Unfortunately for you, that is not working out well.
I think I'm quite entitled to make comparisons between two products and draw my conclusions from that. I still cannot understand where your problem really is, but I hope we'll be able to sort that out, eventually.
> Pointing fingers was childish. When I told you that you were wrong, you were
> pretty quick to say that it wasn't you who stated the facts.
Well, I was just making you notice that you were really saying that Hyperion was wrong, not me. That was meant to show you that you were wrong, or that both of us were right. But you, being so full of yourself, didn't understand that, and preferred to call me names, as if that made that you look better.
> You were just repeating what you thought was common knowledge.
I don't think, I know. Ask your the Friedens, if you don't believe me.
> Now, again, explain to me how an generic m68k function can be called from
> PPC without knowing the ABI. Until you know that,
I knew that even before we started this discussion, it's you who claims that I don't know that. Now you should know too, as I've explained it to you.
> Since you dont know how neither MOS nor AOS4 works,
What, what in the universe makes you believe I don't know how does MOS work? And why is it so difficult for you to accept that the Friedens have claimed more than once that the emulator worked the way I said? Hell, I even remember a PDF paper with pictures that explained it!
> I doubt that you are entitled to be the one to say which solution is the
> most efficient. (Hint since you have failed to provide a solution to the API
> problem, I am assuming that you don't know how it works.)
Your assumption is pretty fallacious, as often happens. Hope you will stop with such bogus claims now, and will understand what I explained above. Somehow I fear it won't suffice, tho :-/
>> So, you don't know how MOS works, by your implicit admission, yet you
>> pretend you know that it can't do things in any other way than AOS4 does?
> Well, I know enought about computers and system design to know what's
> possible and what is not.
:-) So, people, there is is the real Mr. "I know it all"! :-D
Priceless, really :-)
Do you even remotely realize the boldness of such a claim? You said that whatever you come up with must be the only possible solution, because you know "enought about computers and system design". Ahah :-)
Please, pleeeease, you don't even know what do I do in my life, how you even dare making such bold claims? What makes you think you are so much better than me? :-)
Priceless.
> Well, that was the point I was trying to get across. You need to do this
> mapping explicitly. No emulator can handle this completely transparent given
> the ABI used by AmigaOs-m68k
When I say "transparently" I don't necessarily refer to the emulator, I mean transparent to the user and programmer, and MOS' solution does meet both requirements.
> Whining? Care to elaborate? Besides, aren't you the one whining left and
> right about other peoples stupid mistakes and implementations all the time?
> Time to do some useful things instead of spending all your time in forums
> pretending to be 'Mr know it all' ?
Yes? I know left and right whining about other people mistakes and implementations? When would that be? I can only remember having made remarks about design decisions of AOS4, and I think I'm entitled to do them, just like any other person with knowledge of the matters being discussed. If criticism makes me a "Mr know it all", what does your explicit "I know it all" make you?
Besides, I'm spending as much time in the forum as you are, and whatever I do in my life is of no concern neither for you, nor for the matter at hand. But I know that deflection is a common tactic when there's nothing else to say. |
|
| Pre-Realese announcement : Comment 210 of 227 | ANN.lu |
| Posted by Stefan Burström on 17-May-2004 16:17 GMT | In reply to Comment 209 (Fabio Alemagna):
>For God's sake, when and where have I stated such an absurd thing? Since when saying that one particular onefold solution is better than your twofold solution equals to saying that a generic onefold solution is better than any twofold solutions?!
Would you calm down abit please? I was merely trying to point what I was trying to say. Nothing more and nothing less, just to make sure we are talking about the same things, but apparently I hurt your feelings or something?
>> 1) Regardless of what you say, yes, AmigaOS4's emulator worked and to some
>> extents (at least by reading what you are writing) works also now, but only
>> as a "fall back", slow, solution, by intercepting, via MMU, attempts at
>> executing data.
> That is the plan for Petunia, yes, but that is only to help when you are
> emulating ppc converted m68k code that still refers to some non converted
> code.
>If plans have changed again, I don't know, but up to a few weeks ago rogue and company kept saying what I said here before, that is ppc data is considered 68k code when the ppc program tries to execute it. I told you to ask them directly: did you?
No need to, since we were discusing some of these issues internally in the dev team just a few weeks ago. But yes, the fact is still that m68k is still considered data, but that doesn't solve the ABI problem. It just solves the gate beteen JIT'ed and not yet JIT'ed code.
> Believe me or not but there _is no transparent way to bridge between generic
> PPC code and m68k code_ since the ABI's are different. Ask some of the MOS
> developers and I am sure they can explain to you how it works.
>What makes you think I don't talk to MOS developers? I wonder how can you make such bold claims... gee, how can you talk about things you clearly have no clue about?!
Well, solving it by building your own ABI which requites you to have an underlying architecture with >16 registers is of course one solution. But I am willing to sacrifice a few cycles for a solution that is more portable. But hey, that's just my opinion
>Thanks for lectuing me on the SYSV ABI (it's not the PPC ABI, it's one PPC ABI), but I already knew all that.
If you already knew that why did you comment on it? To tell you the truth, you don't seem to know that the ABI for PowerOpen, SYSV and NT are all the same in regards of register passing. That's why I was refering to them as PPC ABI. So, how could I have lectured you on the SYSV ABI then? :-)
>The point is: no guesswork is being done. Simply put, the m68k libraries and
Thanks for the explanation. I still don't know that it was such a good idea to tie the ABI to the m68k architecture, but that is of course just my opinion.
>You really make me smile :-) I can't even get upset, it's just so fun :-)
Well, since you failed to explain things from the beginning, it is rather easy for you to smile I guess...
> Well, I have been trying to understand how stuff works instead of beeing to
> quick judging them to be inefficient, non working or written by bad coders.
> Which from your track record has been more standard.
>I said "inefficient", but I've not said "non working" or "bad coders". It's you who are saying it, and this goes to show that you are so full of yourself that attribute to me things I've never said or implied just so that you can make me look like a fool. Unfortunately for you, that is not working out well.
Right. And it is me who have filled this forums with endless posts and discussions...
>I think I'm quite entitled to make comparisons between two products and draw my conclusions from that. I still cannot understand where your problem really is, but I hope we'll be able to sort that out, eventually.
My 'problem' is that you are comparing 2 products from emotional feelings. And when you are asked about the details you have a hard time explaining them. It wasn't until this post that you actually posted a techical explanation which can be evaluated.
>Well, I was just making you notice that you were really saying that Hyperion was wrong, not me. That was meant to show you that you were wrong, or that both of us were right. But you, being so full of yourself, didn't understand that, and preferred to call me names, as if that made that you look better.
You never mentioned Hyperion until now. You refered to it as common knowledge. And I was trying to explain to you that the world is not just black or white, there are subtile things that might not be 'common knowledge'
> I don't think, I know. Ask your the Friedens, if you don't believe me.
Yeah, I just did that 2 weeks ago, and I didn't get the answer that you are expecting. But otoh, we were discussing a much more in detail thing...
>I knew that even before we started this discussion, it's you who claims that I don't know that. Now you should know too, as I've explained it to you.
You could have done that from the start instead of just saying 'MOS is the proof I need to know I am right'
> Well, I know enought about computers and system design to know what's
> possible and what is not.
:-) So, people, there is is the real Mr. "I know it all"! :-D
Well, redefining the ABI wasn't really an option since I'd prefer to remain portable, but that is just my opinion.
>Please, pleeeease, you don't even know what do I do in my life, how you even dare making such bold claims? What makes you think you are so much better than me? :-)
>Priceless.
Well, what is priceless are your behaviour here at ann. Thats the only impression I have of you. And it is rather, priceless
> Well, that was the point I was trying to get across. You need to do this
> mapping explicitly. No emulator can handle this completely transparent given
> the ABI used by AmigaOs-m68k
>When I say "transparently" I don't necessarily refer to the emulator, I mean transparent to the user and programmer, and MOS' solution does meet both requirements.
Not seen in the MUI sources then... Cause it doesn't seem very transparent to me, but hey, those files are oooold.
>Besides, I'm spending as much time in the forum as you are, and whatever I do in my life is of no concern neither for you, nor for the matter at hand. But I know that deflection is a common tactic when there's nothing else to say.
Huh? Where did I say it was a concern of me? All I was saying is that I treat you the way your reputation calls for. Nothing more, nothing less.
regards,
Stefan |
|
| Pre-Realese announcement : Comment 211 of 227 | ANN.lu |
| Posted by Nicolas Sallin on 17-May-2004 18:50 GMT | In reply to Comment 210 (Stefan Burström):
>Well, solving it by building your own ABI which requites you to have an
>underlying architecture with >16 registers is of course one solution. But I am
>willing to sacrifice a few cycles for a solution that is more portable. But hey,
>that's just my opinion
MorphOS solution only uses registers on architectures able to handle it. Not on
others. So it's portable and fast. You would love it.
>Thanks for the explanation. I still don't know that it was such a good idea to
>tie the ABI to the m68k architecture, but that is of course just my opinion.
I think you would also love MorphOS SYSV libs. |
|
| Pre-Realese announcement : Comment 212 of 227 | ANN.lu |
| Posted by Kjetil on 17-May-2004 20:05 GMT | | I think started some thing wonderful there an technical debate between MorphOS, AROS and OS40 developers :D, for the better for all platforms. |
|
| Pre-Realese announcement : Comment 213 of 227 | ANN.lu |
| Posted by Pixie on 17-May-2004 20:22 GMT | In reply to Comment 211 (Nicolas Sallin):
> MorphOS solution only uses registers on architectures able to handle it. Not
> on others. So it's portable and fast. You would love it.
:? And these other architectures being?? |
|
| Pre-Realese announcement : Comment 214 of 227 | ANN.lu |
| Posted by Kjetil on 18-May-2004 13:38 GMT | In reply to Comment 211 (Nicolas Sallin):
MorphOS solution only uses registers on architectures able to handle it.
Not on others. So it's portable and fast. You would love it.
Not on others, so what are they not able to Handel register using? |
|
| Pre-Realese announcement : Comment 215 of 227 | ANN.lu |
| Posted by Alkis Tsapanidis on 18-May-2004 14:09 GMT | In reply to Comment 214 (Kjetil):
I'm not an expert in this field but I guess that it uses virtual registers for
the 68k.
You can check out the application porting guide, iirc it explains that. |
|
| Pre-Realese announcement : Comment 216 of 227 | ANN.lu |
| Posted by Kjetil on 18-May-2004 15:30 GMT | In reply to Comment 215 (Alkis Tsapanidis):
Fabio made a bole clam that MorphOS uses 1:1 mapping on registers, thay can't use virtual registers |
|
| Pre-Realese announcement : Comment 217 of 227 | ANN.lu |
| Posted by Kjetil on 18-May-2004 16:08 GMT | In reply to Comment 181 (Eva):
This show clearly your ignorance and that you are talking and whuining on your imagination.
The only fast quake showed on Aone was UNDER LINUX, IGNORANT!
Not true the Benelux 2003 event, you are just like my big sister allways teas me,
you are a gloater :) I case you don't know the word you can look it up,
157762620 Oct 5 2003 rotterdamvideovcd.mpg
just skip all that boring MOS stuff inn the beginning :) |
|
| Pre-Realese announcement : Comment 218 of 227 | ANN.lu |
| Posted by Nicolas Sallin on 18-May-2004 16:48 GMT | In reply to Comment 216 (Kjetil):
As I hinted before, MorphOS uses both methods. |
|
| Pre-Realese announcement : Comment 219 of 227 | ANN.lu |
| Posted by Kjetil on 18-May-2004 16:56 GMT | In reply to Comment 218 (Nicolas Sallin):
How do you manage this? are you successful inn getting developers to move over to the new API? |
|
| Pre-Realese announcement : Comment 220 of 227 | ANN.lu |
| Posted by Nicolas Sallin on 18-May-2004 17:51 GMT | In reply to Comment 219 (Kjetil):
MorphOS works like that since 3 or 4 years... Developers never had to change anything. It always was transparent to them, depending on the arch/compiler used. Read the docs. |
|
| Pre-Realese announcement : Comment 221 of 227 | ANN.lu |
| Posted by Kjetil on 18-May-2004 19:58 GMT | In reply to Comment 220 (Nicolas Sallin):
Access denied. Sorry, you don't have sufficient permissions to access this article. |
|
| Pre-Realese announcement : Comment 222 of 227 | ANN.lu |
|
| Pre-Realese announcement : Comment 223 of 227 | ANN.lu |
| Posted by Anonymous on 19-May-2004 09:07 GMT | | Look people, Redhat has just released Fedora Core 2 on May 18 2004. This is the latest, state of the art stuff in operating systems and it's completely free. Grab yourself a $199 complete system from Walmart.com and have fun. Maybe the people at Amiga, KMOS, Pegasis and Hyperion can someday come to terms and port AmigaOS 4.0 to run ontop of Fedora Core 2 (on PPC and X86) and create a new Linux distribution, but how many heartbeats are you willing to waste waiting? In my anonymous opinion, AmigaLinux makes a Hell of a lot more sense than AmigaDE for Java, AmigaOS 4.0 for some specific PPC cards, or MorphOS ever did. Anyway, anything AmigaXXX can do, Linux can now do better, so go download Fedora Core 2 and burn the iso's onto CD-R and have a ball. |
|
| Pre-Realese announcement : Comment 224 of 227 | ANN.lu |
| Posted by Anonymous on 19-May-2004 15:33 GMT | In reply to Comment 223 (Anonymous):
> Anyway, anything AmigaXXX can do, Linux can now do better, so go download Fedora Core 2 and burn the iso's onto CD-R and have a ball.
You are apparently immune to the frustrations that average users experience with Linux. It's not a good operating system for home computers and average users. The percentage of Linux users, in spite of beeing free and all that, hovers near 5% for many years in a row now. Besides, we do not prefer AmigaOS/MorphOS because it "can do" something (we have a PC for that, if push comes to shove) but because WE want to do something: it is fun to program. Linux doesn't look like fun to program: it is intimidating, complex and I'd expect a long learning, frustrating curve. |
|
| Pre-Realese announcement : Comment 225 of 227 | ANN.lu |
| Posted by Kjetil on 19-May-2004 16:20 GMT | In reply to Comment 222 (brotheris):
Tryed www.MorphOS.net, I have bookmarket your link,
sound like what we have debated, more or less, I compare it when I get my AmigaOS40/SDK just for fun.
tanks. |
|
| Pre-Realese announcement : Comment 226 of 227 | ANN.lu |
| Posted by Kjetil on 19-May-2004 16:24 GMT | In reply to Comment 224 (Anonymous):
SDL, OSS, and your done. |
|
| Pre-Realese announcement : Comment 227 of 227 | ANN.lu |
| Posted by Mikael Burman on 20-May-2004 01:17 GMT | Hahahahaha....and...
hahahahahaha....
and...hehehehe....and
hehehehehe...
Did I make any sense? No? Hmm...strange... but wait... I... I thought I heard something... must check it out....
99% of all anonymous posts in this thread could be translated to what I wrote above... cool!!! |
|
|
- User Menu
-
- About ANN archives
- The ANN archives is powered by #AmigaZeux. It was updated daily (news last: 22-Oct-2004; comments last: 18-May-2005).
ANN.lu was created, previously owned and maintained by Christian Kemp, www.ckemp.com.
- Contribute
- Not possible at this time!
- Search ANN archives
- Advanced search
- Hosting
- ANN.lu was hosted by Dreamhost. Sign up through this link, mention "ckemp" as referrer and he will get a 10% commission on any account you purchase.
Please show your appreciation for any past, present and future work on ANN.lu by making a contribution via PayPal.
|
