Login
Username:

Password:

Remember me



Lost Password?

Register now!
Main Menu
Who's Online
1 user(s) are online (1 user(s) are browsing Forum)

Members: 0
Guests: 1

more...

Browsing this Thread:   1 Anonymous Users



« 1 2 (3) 4 5 6 ... 14 »


Re: Vampire hyper threading and aros smp

Joined:
2013/4/21 1:35
From Germany
Group:
Member
Posts: 275
Offline
Quote:

rollmeter wrote:
Quote:

cdimauro wrote:
Quote:
To cdimauro:

I never told Power PC or POWER or customized POWER (OpenPOWER) are outside of server market, there was a comma between "too" and "outside" on my post ;)

Which should mean "and", so you've added another "quality" to the PowerPC family.


Nop... You are wrong, and trying to modify what I said is not a good way to answer.

Quote:
At least, that's what I've understood.


Yeah, you understood that, but instead of changing your words, you decided to correct me despite not being errors on my statement...

Here's your statement:

"PowerPC Amiga computers are not compatible with old code (only with emulation), relative fast and now arquitecture is obsolete too, outside from server´s market."

Please, explain the meaning of the last sentence in the context of PowerPC.

I haven't pretended to change your word: I replied as I understood, and I still think that I've understood correctly.

Now it's your turn to clarify what you mean. IF you want to do that, but looking at your message I think it's unlikely, because it's not your interest.
Quote:
Quote:

Quote:
That's why I think there is no problem with new enhacements too... 64 bits, MMU, AMMX, different FPU... All it's ok, an abstraction layer/driver do the work...

The 4 things that you've mentioned aren't abstraction layers, but features.


Second time... Again you are correcting what it is not wrong and you are telling something everybody knows... Why are you trying to modify what I said?

Here's what YOU stated:

"That's why I think there is no problem with new enhacements too... 64 bits, MMU, AMMX, different FPU... All it's ok, an abstraction layer/driver do the work"

Please, explain which kind of abstraction layer/driver you were talking about such new features. What they should do?

You can go as technically deep as you can: I've a very good understanding of the 68K/x86/x64 architectures, and a good-enough understanding of the Amiga o.s. structure.

You can also give concrete examples in whatever language you want: assembly, C/C++, Pascal, Fortran, ecc... I accept also machine language for the above architectures, without problems.

Let's put on the table some concrete stuff, because... words are cheap and you are just spreading words.
Quote:
Click to see original Image in a new window

Quote:

Quote:
Regarding X86 CPUs and hardware compatibility, there are device drivers and software layers managing that compatibility you are talking about too. So, there is not a full compatibility between nowadays X86 CPUs and old ones.

There's no compatibility layer: the x86 CPUs are still able to run 8086 software without requiring a compatibility layer.

From:

Intel® 64 and IA-32 Architectures
Software Developer’s Manual
Combined Volumes:
1, 2A, 2B, 2C, 2D, 3A, 3B, 3C, 3D and 4,

at pag. 65 (in the PDF):

"The IA-32 architecture supports three basic operating modes: protected mode, real-address mode, and system
management mode. The operating mode determines which instructions and architectural features are accessible:
[...]
Real-address mode — This mode implements the programming environment of the Intel 8086 processor with
extensions (such as the ability to switch to protected or system management mode). The processor is placed in
real-address mode following power-up or a reset."

As you can see, an x86 (and x64 too) processor still wakes-up in the old real-mode, running 8086 instructions.


Again... You did it again, 3 times now, Incredible... Click to see original Image in a new window

Click to see original Image in a new window

You can attach 1000 page manual if you want... But tell me please... Why are you trying to correct me with arguments that are not related to my words, man...?


I don't need it. Here's, again, what YOU stated:

"Lets try to run old code on an i7/i9/Ryzen CPU without emulator, drivers or patches and let´s see what happens... Because there is no fully compatibility too with an old 8086, 80286, 80386 PC...."

That's completely false, because it's clear that you have absolutely no idea of how a PC works, even nowadays. That's why I've reported a part of the Intel's architecture manual: to shows the complete non-sense that you've written.

And again you repeated yourself:

"Regarding X86 CPUs and hardware compatibility, there are device drivers and software layers managing that compatibility you are talking about too. So, there is not a full compatibility between nowadays X86 CPUs and old ones."

Another completely false statement, which Intel's Manual rebuts, since a PC starts in the very old 8086 mode, without any driver or compatibility layer involved.

It's simply that you have absolutely no idea of how a PC works: you write things only because you have a keyboard, like it happens in the internet age, where everyone pretends to says his opinion, even if it's plainly wrong, only because it's allowed to do it and spread it around the world.

Now you have the chance to prove the contrary: please, explain me how such drivers / abstraction - compatibility layers work on a PC: it's YOUR words.

Again, you can go as deep technically as you want: I have no problem following you.

And to be more clear, YOU have to prove it as science and logic commands: the burden of proof is your.
Quote:
Quote:
cybergorf just reported how is the situation: they made/make false statements.


Nop, they don´t... I have been reading Apollo forum posts and statements from the begining and they give what they say.

That's completely false, again. They reported precise information about 100% 68K compatibility, and even a fully working FPU.

Some people complained about it (reporting text from the Apollo site which proved it) in a specific thread talking of the FPU, and Gunner COMPLETELY DELETE IT!

Anyway you can say whatever you want: it doesn't change what cybergorf reported, which everybody can verify.

It's just your words, which have zero value, against the precise statements that cybergorf reported from the Apollo site (read: it's NOT his opinion / words).
Quote:
But now I see the way you read my comments, and how you change and try to modify my words... So I can understand now why you think that about them...

It seems that you are the only one that understand what you have written...
Quote:
Quote:

Quote:
68K is easy to code, and an enhaced version is good for Amiga world, it's good for other old computers, servers, and industrial equipment using old 68K too. CPUs that can not be replaced by an ARM or X86 board.

Nobody outside of the retro fans micro-niches are interested in having another 68K processor.

And only insane people can think to start again writing 68K code in assembly, except for small, strategical pieces.


Better to say you don´t like it and you are not interested on it. Good... :)

That's the only true thing that you've reported: yes, I don't like it, because assembly is an absolutely not productive language.

I prefer Python for the opposite reasons.
Quote:
Insane people? Why? Then are you sane despite you modify people´s words and statements? Click to see original Image in a new window

First you have to prove that I've changed your words, and now you have the chance to do it.

Second, as I said assembly is one of the worst languages in terms of productivity (second only to the machine language).

Since software is a quite complex beast nowadays, it's insane thinking to continue writing it in assembly (like what I did from the beginning of the 80s to the middle of 90s).

But you can prove me wrong even on this side, if you want: please, start writing an entire o.s. in 68K assembly, if you think that it's so nice to work with it.

AROS is written (mostly) in C, so it's not a good candidate for Vampire next o.s.: rewrite it in assembly (fully using the above new Apollo's features), and let me know when you're done.

If you don't like writing o.ses, you can still have the chance to write drivers, tools, and entire applications: there's room for everything.

One of the things which is absolutely mandatory nowadays is a browser: fully HTML5-compliant, with Javascript, and especially with a JIT compiler for Javascript. Let's start it, and let me know when you've finished it: I'm here warmly waiting for your great work...
Quote:
Quote:

You remind me Matt (matthey): another dreamer.

You remind me Pedro Sanchez (Spaniard Politician). He has the ability to change what people say to disqualify them, fighting with them despite nobody is fighting with him and he think he has the only truth, his truth... If he think snow is green, then everybody is wrong...

Fortunately everybody knows about his toxic way of managing conversations, so people prefer preventing problems with him...Click to see original Image in a new window
Click to see original Image in a new window

Cheers,
Rollmeter

You, instead, remind me a common figure in the internet land: a troll.

But you've the chance to prove me that I'm wrong: see above.

But don't let me get too much old waiting your (technical) answers: I've only one life...

Posted on: 6/25 21:52
Transfer the post to other applications Transfer


Re: Vampire hyper threading and aros smp

Joined:
2010/8/30 7:20
Group:
Member
Posts: 947
Offline
Quote:

Overflow wrote:

I have absolutely no illusions about what can be accomplished, but I do think bounties stand a better chance now compared to the past.


im with you on this, even though i dont think we have arrived at a necessary point of awareness yet, but we might be underway.

Posted on: 6/26 1:26
Transfer the post to other applications Transfer


Re: Vampire hyper threading and aros smp

Joined:
2004/4/7 4:26
Group:
Member
Posts: 4358
Offline
Quote:

cdimauro wrote:

A niche fighting against another niche for supremacy / leadership / revenge doesn't change the situation: it remains a niche, and will not impact the real world.


I wonder where exactly do you see all this fighting for supremacy, I guess all the sane people still interested into Amiga stuff have now understood how much retro this platform is and how much it hits the mainstream computer market (zero). However, there are a few people and companies which still consider this "sell me hundreds" kind-of niche a market, and make considerably ridiculous statements about 'competition', 'supremacy', sometimes acting with very silly and pathetic behaviors on forums, social networks and so on. So please ignore them and just enjoy the very little this community can produce. All people here are perfectly aware of the fact that any enhancement to the old 68K platform will be of interest/amusement for a very little niche, and it won't restart anything, nor it will bring back Amiga computer from the grave the market has already buried them in. We're still writing/enhancing AROS mainly for fun, don't forget that.

Posted on: 6/26 1:32
_________________
p.bes
Icaros Desktop AROS distribution mantainer
Transfer the post to other applications Transfer


Re: Vampire hyper threading and aros smp

Joined:
2010/8/30 7:20
Group:
Member
Posts: 947
Offline
Quote:

cdimauro wrote:

I know the situation that you reported. But, as I've already stated, it's not happy.

it wasnt happy to start with, but whatever.

Quote:

I know this also, but it's still incomplete for the pure 68K family, and maintaining a mega-patch over the regular branch is already not simple (read: it needs to be upstreamed to become easier to handle).

aros maintains patches to gnu toolchain all the time, without pushing them upstream, even though this is kept as option, we are now at gcc6.3 same as bebbo, so we are up to date.
also i have read bebbos patches and it looks rather cleanly structured, most severe changes are in few additional source files, while patches to the original sources are reasonably small. it is not ideal to have a compiler patched locally, but it looks maintainable.
also it is close to be complete i guess. toni wants it for aros and bebbo wants to compile aros with it. win-win.


Quote:

A niche fighting against another niche for supremacy / leadership / revenge doesn't change the situation: it remains a niche, and will not impact the real world.

as if i broke that war off or expected 68k to go mainstream again.

Posted on: 6/26 1:38
Transfer the post to other applications Transfer


Re: Vampire hyper threading and aros smp

Joined:
2011/3/7 1:41
From Nürnberg, Deutschland
Group:
Member
Posts: 1347
Offline
@cdimauro

nobody with sane mind would even think about becoming mainstream again. Even if one of the amiga platforms evolves to something technical up to date who outside would want to use it because of the lack of up to date software. And no software developer will develop for it because of lack of potential buyers. So all platforms are "retro" now, some more some less. Apollo/Vampire is of course retro too but as most available software still used on amigas is 68k (and that includes development environments and compilers) Apollo/Vampire cards and future standalons together with aros at least offers some chances. For Aros it is the big chance to get the public support it always deserved, I cannot see something wrong in it.

Posted on: 6/26 2:40
Transfer the post to other applications Transfer


Re: Vampire hyper threading and aros smp

Joined:
2015/7/29 23:57
From France Bordeaux
Group:
Member
Posts: 39
Offline

@wawa

Quote:
@wana aros maintains patches to gnu toolchain all the time, without pushing them upstream, even though this is kept as option, we are now at gcc6.3



Why the new toolchain is not publish with the SDK ?

Posted on: 6/26 3:03
Transfer the post to other applications Transfer


Re: Vampire hyper threading and aros smp

Joined:
2010/8/30 7:20
Group:
Member
Posts: 947
Offline
Quote:

sadirux wrote:
Why the new toolchain is not publish with the SDK ?


i dont know any sdk that is published. probably along with a distribution? then its all abi v0, which is obsolete imho but kept for compatibility upgraded moderately from v1 where appropriate.

platforms where most current developments takes place,that is x64(smp), arm(?) and amiga-m68k are abi v1.
you will obtain the latest toolchain for your target compiling aros with "--with-binutils-version=2.25 --with-gcc-version=6.3.0".

Posted on: 6/26 3:20
Transfer the post to other applications Transfer


Re: Vampire hyper threading and aros smp

Joined:
5/24 4:59
From Norway
Group:
Member
Posts: 33
Offline
Quote:
Some people complained about it (reporting text from the Apollo site which proved it) in a specific thread talking of the FPU, and Gunner COMPLETELY DELETE IT!


I was the starter of that thread (Mr Niding on Apollo forum), and after some thought I was ok with the deletion since it started to take Amigaworld.net directions in quality.
The reason why I started the thread was cause it was hard getting a direct answer to the FPU compability question. Gunnar sometimes talks more like a artist than a coder. Creative. So both me and Skipp got quite annoyed with him on IRC since he just couldnt answer DIRECTLY to a very DIRECT question.

BUT after a while, Ive taken a "appriciate what has been made so far, and have some faith in the direction the team is taking the project".
For me as a END USER, the Vampire is already outstanding, from a expirience point of view. I realise for a developer/coder at yours and Toni Wilen level that expirience might be completely different since you require a userfriendly development eviroment.

Maybe the core FPU will not be 100% compatible with the legacy hardware, but then the question is; can a emul lib use the new Apollo FPU and utilize a more advanced FPU design? Basically FPU isnt 100% compatible, but it wont be needed cause its secured softwareside/libs...?

I realise I might be talking out of my arse ;)

Posted on: 6/26 4:11
Transfer the post to other applications Transfer


Re: Vampire hyper threading and aros smp

Joined:
2015/7/29 23:57
From France Bordeaux
Group:
Member
Posts: 39
Offline
Quote:

wawa wrote:
Quote:

sadirux wrote:
Why the new toolchain is not publish with the SDK ?


i dont know any sdk that is published. probably along with a distribution? then its all abi v0, which is obsolete imho but kept for compatibility upgraded moderately from v1 where appropriate.

platforms where most current developments takes place,that is x64(smp), arm(?) and amiga-m68k are abi v1.
you will obtain the latest toolchain for your target compiling aros with "--with-binutils-version=2.25 --with-gcc-version=6.3.0".


When I say SDK, I think about this :

http://netcologne.dl.sourceforge.net/ ... 70626-pc-i386-sdk.tar.bz2

or this

http://netcologne.dl.sourceforge.net/ ... 624-pc-x86_64-sdk.tar.bz2

This are not the official SDK for Aros ??

Can I compil aros abv1 under aros abv1 ?

Posted on: 6/26 4:49
Transfer the post to other applications Transfer


Re: Vampire hyper threading and aros smp

Joined:
2010/8/30 7:20
Group:
Member
Posts: 947
Offline
yes, these appear to be current abi v1 aros sdks. however gcc-4.6.4 is still default compiler. the 6.3.0 is optional, you will have to compile it yourself.

it may be already possible to compile aros under aros, though i doubt if it completes. the most dependable option is still to cross compile it under linux. i am using lubuntu under vm for this purpose.

here is an example configure invoke from separate build dir on the same level as the source.

../AROS-source/AROS/configure --target=linux-i386 --with-serial-debug=yes --with-portssources=/home/wawa/portssources --with-binutils-version=2.25 --with-gcc-version=6.3.0

(portsources optionallows you to buffer source packages locally.) then you simply hit make.


Posted on: 6/26 5:18
Transfer the post to other applications Transfer



« 1 2 (3) 4 5 6 ... 14 »



You can view topic.
You cannot start a new topic.
You cannot reply to posts.
You cannot edit your posts.
You cannot delete your posts.
You cannot add new polls.
You cannot vote in polls.
You cannot attach files to posts.
You cannot post without approval.

[Advanced Search]


Search
Top Posters
1 paolone
paolone
4358
2 magorium
magorium
4095
3 phoenixkonsole
phoenixkonsole
3892
4 nikolaos
nikolaos
3693
5 deadwood
deadwood
2923
6 ncafferkey
ncafferkey
2644
7 mazze
mazze
2214
8 clusteruk
clusteruk
2109
9 Kalamatee
Kalamatee
2024
10 damocles
damocles
1789
© 2004-2017 AROS Exec