Login
Username:

Password:

Remember me



Lost Password?

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

Members: 3
Guests: 1

wawa, cybergorf, SpeedD408, more...
   All Posts (cdimauro)


(1) 2 3 4 ... 26 »


Re: Vampire hyper threading and aros smp

Joined:
2013/4/21 1:35
From Germany
Group:
Member
Posts: 255
Offline
Don't insult peoples intelligence, and show some respect for yourself.

You attacked me telling that I spread lies, writing your usual wall-of-text, and I've just defended myself and replied to all your points even technically.

You're free to ignore my reply if you don't like to continue, and the discussion ends here: we all expressed our point-of-views, and who reads can make his opinion.

But nobody stops you to ALSO talk about your HyperThreading implementation.

The two things aren't mutually-exclusive: that's just elementary logic.

Now you can explain your HT implementation. If you REALLY want.

Posted on: Yesterday 21:38
Transfer the post to other applications Transfer


Re: Vampire hyper threading and aros smp

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

OlafS3 wrote:
@cdimauro

if you would read my statements carefully you would understand that I never wrote something about "revival" in sense of former glory, my view is zero chance for NG including MorphOS and AmigaOS and the big Aros versions because of no software. There might be a small chance of some sort of "revival" (that would be more users and developers relative to now) for new 68k hardware combined with Aros 68k because 90% of amiga software is for 68k only, in many cases not portable because written in asm or no sources. People indeed use software (or apps how it is called today) not OS features. Even if one of the platforms gets modernized and is up to date there will be no new users and software because users use software and developers write software but are not interested as long there are only few users. And if there is only few software it is difficult to attract more users. It is difficult to get out of that circle how even Trevor D. despite his money has to realize. I think what I write is very logical.

Yes, it is.

I'm only a bit skeptical about expanding the developers and/or user base.

Posted on: Yesterday 13:45
Transfer the post to other applications Transfer


Re: Vampire hyper threading and aros smp

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

biggun wrote:
cdimauro,

you are either very mis-informed and are senselessly posting very wrong stuff
Or you are a liar and post on purpose FUD.

I've reported documentation from YOUR sites and the 68080 manual, which "strangely" you carefully avoided to quote and give a proper answer.

If you see some lies, well, YOU are the source of them, since I've just used a very common tool: copy & paste.

Correct YOUR sites and the documentation, and the problem is solved.

As I've already said, you spend TONs of time writing Egyptian papyrus, but don't find some minutes to correct the above situation.

For me it means that you do it on purpose, because you like to swim (and take advantage of) in this situation.
Quote:
Lets clear some of the FUD up.

1) APOLLO 68080 is really 100% 68K compatible.
APOLLO does implement every 68K family CPU instruction.
Apollo does also implement all 68K family address modes.
Apollo is the only FPGA core doing this.
Apollo also supports all instruction which the 68060 does not support like e.g. MOVEP or MUL64

The 68060 has built-in AND working MMU and FPUs. The 68080, as advertised (see the documentation that I and cybergorf have reported)... NO!
Quote:
2) APOLLO has an MMU
This MMU is used many times on the VAMPIRE.
You use this when using MAPROM.
Its used when enabling "Chipmem Expansion"
On the Vampire you can virtually expend the chipmem and have 2/4/or even 128 MB chipmem also on Amiga 1000.

But an MMU is a complex feature.
The APOLLO MMU does offer more and stronger features than any of the old 68k MMUS.
For example you can "protect" memory not only from read but also from execution and you can use the MMU to shadow memory regions.
An OS not knowing all the features of the MMU could easily misconfigure it. As no 68K-MMU is compatible to the others MMUs of the family this is tricky for AMIGA OS 3. Therefore the APOLLO MMU is currently "hidden" and private until proper support to the OS is added. But maybe this support get easier added to AROS.

You should know better than me how different are all 68K processors, how they work, and how they are recognized and correctly used by the software.

This is how your "68080" is recognized:

Click to see original Image in a new window

A 68EC040. Let's split it: 68040, but the specific EC version!

So you decided ON PURPOSE that your core is viewed like THIS PARTICULAR member of the 68K family, which isn't a fully featured 68040 (your screenshot clearly shows the lack of MMU and FPU).

Now, please tell me: who stops you from enabling your MMU, if it's really there, and let it be used as a 68040 exposes it?

Nobody: it's YOUR decision to let your MMU being enabled, and used as the one integrated in the 68040, since YOU decided that your core is recognized as a 68EC040.
Quote:
3) APOLLO can of course catch NULL-Pointer access and access to non-existing memory areas.
This feature is also available in the Vampire.

4) APOLLO has a full 80bit FPU including all instructions of the 68040 and 68060 Hard-FPU. All instructions are in operation and encoding 100% compatible.
But this FPU is in the Vampire2 not enabled currently as size fitting it in the FPGA requires more time and the teams is focusing today fully on bringing first out the new Standalone and new V1200 cards.

But you have plenty of time and resources (128 64-bit registers is the last data that you reported) to implement:
- 64-bit registers;
- 16 address registers;
- 24 extra registers for AMMX (which, as I've stated, is an horrible patch over the 68K. ALL other modern ISAs do NOT use GP registers for this stuff: either they share them with the FPU, or have a proper, separate set specifically for the SIMD unit);
- AMMX instructions;
- Hyperthreading.

It's YOU that decided to spend A LOT of resources & time for things which are totally alien to the 68K family, instead of implementing what's part of such processors from very long time, and with already available software using them.

Cut such extra, alien stuff, and introduce what customers already demanded from long time: FPU and MMU (which is already there, according to what you said above. So you shouldn't need neither resources nor time for enabling it).

You can be a great VHDL engineer, but you have to learn three things:
- listen customers. Yes, you've customers now, and it's more important to satisfy their pretty REASONABLE needs instead of playing like a kid with your new toy, implementing whatever you think is important;
- publish CORRECT, not misleading/confusing/hope-raising information. It requires MINUTES, not days to do it: write less messages, reduce their size, and use the recovered time for this much more important task;
- accept critics. Here's a question of maturity, and you should have been grown enough to understand what it means.

And pay attention: nobody is denying that the Apollo core which is found in the current boards is a great, innovative product. It's, as I've already stated. And kudos for having delivered it.
Nevertheless... it has its issues, included incorrect advertising.
Quote:

biggun wrote:

Maybe this forum here could also benefit from some "cleanup".

And another thing: censorship isn't the right thing to do or claim, when you see things that you don't like.

Respect peoples opinions, even if they are sensible critics to what you did.

Posted on: Yesterday 13:36
Transfer the post to other applications Transfer


Re: So... what are we?

Joined:
2013/4/21 1:35
From Germany
Group:
Member
Posts: 255
Offline
I've no time, but I want to give a quick opinion about the argument.

IMO AROS is not exactly retro because it brings some modern stuff (64-bit), and there's work-in-progress for anoother very important (and common in the mainstream) thing which is SMP.

Unfortunately it lacks a lot of even more important things: memory protection, resource tracking, security (user privileges & co.), multi-user (related to the previous), a modern file system.

Another thing which unfortunately is really odd is the fact that you have the specify the stack usage for an application, otherwise it might crash: that's weird!

So, there's still a lot of work to do, and I'm perfectly aware that it might completely hurt its nature, since all those defects are an unfortunate Amiga o.s. heritage, and removing some of them might mean the end of AROS as an Amiga o.s. replacement/rewrite.

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


Re: Vampire hyper threading and aros smp

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

paolone wrote:
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.

Quote:

OlafS3 wrote:
@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.

Quote:

wawa wrote:
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.

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

I've very little time, since I've to go work, but I want to quickly write something about it.

We all follow the same forums (Amigaworld, primarily), so we should have read statements about such 68K revival. I don't have time to make an extensive search now, because it takes too much.

And to be clear: I'm not talking about only matthey or samuraicrow, which are 68K advocates. Even you, Olaf, expressed similar positions AFAIK (not only because of the 10x amount of 68K software compared to all the rest).

For rest, I think we are aligned: AROS can help the 68K platform, and can also receive improvements. A win-win situation: good!

Quote:
Quote:

cdimauro wrote:

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.

OK, that's a very good thing, since GCC is mess.
Quote:
also it is close to be complete i guess. toni wants it for aros and bebbo wants to compile aros with it. win-win.

I remember that many things were still missing, and I haven't seen any update from some months.

But if you are in touch and you know that only a bunch of things are missing, that's a very good new.

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


Re: Vampire hyper threading and aros smp

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

Overflow wrote:
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.

I know it: he repeatedly refused to give a simple answer to the very simple question that you asked.

Instead, he has written SEVERAL messages, even LONG ones, talking of different things.

He finds time, A LOT of time, for expressing HIS opinions, but doesn't find a few seconds (that was enough) to answer a simple customers question...
Quote:
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.

That's a completely different thing, and I agree. Nothing say.

The only problem is related to the false statements & propaganda that they are still making.
Quote:
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.

In fact, think about developers which have to develop something. Without an MMU, you cannot catch null pointers de-references or other illegal accesses, which unfortunately are very common when using low-level languages like assembly or more high-level languages which use pointers.

You have to develop the "old way": compile, run, crash -> reset the machine. Not so much productive.

And emulator can greatly simply the life here, but Toni doesn't want to expand WinUAE to support the Apollo core, with good reasons.

BTW, an MMU isn't only important for developers, since some applications used it too (some emulators and virtual memory implementation, AFAIK), and that's part of the regular user experience.
Quote:
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 ;)

It's a forum: talking is its primary purpose.

I understand why Gunnar doesn't want to implement (or expose, if it's already there) a regular 68K FPU, but the problem is that there's software that use it.

Yes, in the future there might be GFLOPS of processing power using the next generation FPGAs, but only in single or (at most) double precision, and in any case Gunnar doesn't seem to offer it with a regular 68K FPU, but it wants to do it with its SIMD implementation, which is clearly a new and incompatible thing.

IMO they should provide a 68K FPU (and MMU too) in order to allow users to use ALL 68K software, and so being 100% compatible.

If they don't want to put too much silicon for it, they can find different ways.

I've find a good compromise with my (new) architectures, which are 100% source compatible (even assembly) with x86 & x64, so it's possible to execute all legacy instructions. Not at full speed, but at an acceptable speed: a good compromise, to say. And everything without wasting too much silicon (on the contrary: the legacy stuff requires only a bunch of resources). But it's my stuff, and I will not share the mechanism, because I might patent it in future (of course, if nobody did the same before ).

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


Re: Vampire hyper threading and aros smp

Joined:
2013/4/21 1:35
From Germany
Group:
Member
Posts: 255
Offline
I know what happened, since I follow the forum (after that the Natami project substantially died). I'm passionate about computer architectures, and 68K was one which I've loved.

Yes, finally they added that sentence. Nevertheless, if you look here http://www.apollo-accelerators.com :

"Apollo Accelerators is an Amiga Classic accelerator board product line. It uses the Apollo core which is a code compatible Motorola M68K and ColdFire processor but is 3 to 4 time faster than the fastest 68060 at time.
[...]
Fastest Amiga CPU
Faster than a 68060 at 100MHz, capable of Next Gen workloads (watching movies, listening to digital music, etc.)
[...]
Where to buy
Vampire 600 V2 Vampire 500 V2+ Vampire 1200
[...]
Team
Gunnar "BigGun" von Boehn (CPU Designer)
Christoph "ceiach" Hoehne (CPU Designer)
Igor "Majsta" Majstorovic (Hardware Designer)
Brian "kipper2k" Robotham (Hardware Designer)
cgugl, flype, freemilk, grond, guibrush, mfilos, Ng, ShK and TuKo (test team)
and all the missing others !
[...]
Contact us
Need more information ? Just get in touch with us !
Also join us on IRC (Freenode) in #Apollo-Team channel."

So, it seems that this is their site, where they happily mix the apollo core and the cards which use it.

In fact, you can find a similar mix into the Apollo (NOT Vampire!) datasheet: http://www.apollo-accelerators.com/files/Apollo_datasheet.pdf

"Apollo core based accelerators line-up
V600 V2
V500+
V1200
Standalone"

And more important:
"About core : http://www.apollo-core.com/
About accelerators : http://www.apollo-accelerators.com/"

So, the connection between accelerators and cores is clearly evident, and I can say that maybe it really wanted at this point.

Anyway they continue to spread false statements, like that it's faster than a 100Mhz 68060. That's simply not true, since the FPU is not enabled (you can claim whatever you want, but if it's impossible to use it then... it's NOT there!) and tests made by ALF42 (if I recall correctly) shown that the current Apollo core inside the Vampire is between 30 and 300 times SLOWER than a 50Mhz 68060 (running executables with native FPU support).

Another false statement is the 100% compatibility, and much more, that they claim, even in the the apollo core. Looking at the features page: http://www.apollo-core.com/index.htm?page=features

Guess what's missing: the MMU!

They "forgot" to mention it in the features list, otherwise a dangerous red box would have appeared in the 68080 column, and green ones at least in the 68040 and 68060 ones: bad propaganda!

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


Re: Vampire hyper threading and aros smp

Joined:
2013/4/21 1:35
From Germany
Group:
Member
Posts: 255
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:
2013/4/21 1:35
From Germany
Group:
Member
Posts: 255
Offline
Quote:

wawa wrote:
[... about contributors ...]

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

Not even talking about a compiler support for such new features, which is missing (and the plain 68K support just sucks).

we have bebbo with his m68k gcc6.3 backend.

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).

I doubt that someone can add what's missing for supporting the new Apollo features: there's so much work to do.
Quote:
Quote:

I don't have to tell you that the situation is certaily NOT happy, because you follow all post-Amiga forums, and you already know it.

actually thanks apollo it is not that bad as it would be otherwise. nge amiga is burning out, unfortunatelly, on all fronts, only 68k sustains at a low level admittedly. thats where ng led us ignoring 68k for so long.

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'm pretty sure that Apollo will give a good contribute / toy to the 68K aficionados, but it's still a retro-niche.

P.S. I wouldn't call a port as "NG": there's nothing "NG" on a port of an o.s. to another platform. NG for me means that the new platform solves at least some serious problems of the old one, which is not the case in the post-Amiga land.

@Overflow: bounties might be a solution, but someone should write them, and start putting some money.

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


Re: Vampire hyper threading and aros smp

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

wawa wrote:
Quote:

cdimauro wrote:

Apollo is claimed to be 100% 68K compatible, but that's simply not true, since it lacks an FPU and an MMU. I mean, one of the 68K FPUs / MMUs which were used by the Amiga software.


then 68000 is itself not 68k compatible since it lacks fpu and mmu. hell 68020 is not compatible! here already go two cpu models built in most popular amiga hardware, not to talk of few more. we arriva at a conclusion amiga was basically not 68k compatible, according to your reasoning.

Take a look at what cybergorf reported.
Quote:
but lets not split hairs.

The point which I (and not only me) raised is about useless features (in the Amiga/68K land): 64 bits, incompatible MMU, AMMX, and now HyperThreading.

As I said, there's no software and not even o.s. support for them.

A regular FPU, MMU, and out-of-order execution are much more useful, and immediately usable by already existing software.
Quote:
there is at least two factors i as see advantageous in 68k platform for aros as a whole:
1. it allows or rather motivates people to test low end hardware, which eventulally may lead to improvements in cross platform effectivity of the system. we have already seen the results.

I agree.
Quote:
2. it may actually improve overall aros popularity, gaining some user base, no matter what platform, and perhaps even attract developers. also this is something we have already seen the results of, with most prominent example being jason and toni.

But here I don't agree.

Jason substantially disappeared. About Toni, I've reported a couple of links, and you should know the situation. deadwood (which might have helped on the 68K side) completely disappeared. kalamatee might be interested, but I think that bounties are needed in this case (he makes A LOT of work, and deserves some compensation IMO).

Not even talking about a compiler support for such new features, which is missing (and the plain 68K support just sucks).

I don't have to tell you that the situation is certaily NOT happy, because you follow all post-Amiga forums, and you already know it.

Quote:

cybergorf wrote:
Quote:

wawa wrote:
Quote:

cdimauro wrote:

Apollo is claimed to be 100% 68K compatible, but that's simply not true, since it lacks an FPU and an MMU. I mean, one of the 68K FPUs / MMUs which were used by the Amiga software.


then 68000 is itself not 68k compatible since it lacks fpu and mmu. hell 68020 is not compatible!


The Apollo-Core homepage lists under features of the Apollo 68080 CPU:
"Fully pipelined, double/extended FPU"
http://www.apollo-core.com/index.htm?page=features

Under products it says both available cards do have the "Apollo 68080 CPU"

Ergo, a customer has to assume, this product has a "100% code compatible" fully pipelined FPU.

This was criticized more than once in the Apollo-forum, but for unknown reasons, the Apollo-team chooses to mislead new customers.

Don´t get me wrong: I will buy one nevertheless, as soon as the standalone is available, but I do not understand such behavior.

+1

Posted on: 6/25 12:23
Transfer the post to other applications Transfer



 Top
(1) 2 3 4 ... 26 »




Search
Top Posters
1 paolone
paolone
4332
2 magorium
magorium
4095
3 phoenixkonsole
phoenixkonsole
3887
4 nikolaos
nikolaos
3677
5 deadwood
deadwood
2923
6 ncafferkey
ncafferkey
2599
7 mazze
mazze
2202
8 clusteruk
clusteruk
2065
9 Kalamatee
Kalamatee
2018
10 damocles
damocles
1789
© 2004-2017 AROS Exec