Welcome, Guest. Please login or register.

Author Topic: How to move AROS forward  (Read 30538 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline yakumo9275

  • Sr. Member
  • ****
  • Join Date: Jun 2008
  • Posts: 301
    • Show all replies
    • http://mega-tokyo.com/blog
Re: How to move AROS forward
« on: July 24, 2008, 10:40:04 PM »
Can I be blunt too?

Are you on the aros developers mailing list?
Have you committed code to the svn repository?
What can you do to help move it forward?

--/\\-[ Stu ]-/\\--
Commodore 128DCR, JiffyDOS, Ultimate 1541 II, uIEC/SD, CBM 1902A  Monitor
 

Offline yakumo9275

  • Sr. Member
  • ****
  • Join Date: Jun 2008
  • Posts: 301
    • Show all replies
    • http://mega-tokyo.com/blog
Re: How to move AROS forward
« Reply #1 on: July 25, 2008, 01:44:37 AM »
Quote
uncharted wrote:
I fail to see what that really has to do with it.  I really wish that people would stop hiding behind open source as if it is some sort of licence to absolve their projects of any criticism.  If this didn't happen in the first place I wouldn't have to be so blunt in my original post.


What it tells me is you have no investment in AROS, and it is some minor form of absolvment from criticism, because if you dont like it, you have all the rights in the world to go do something about it, make your own fork. Start writing code to get that fork where YOU want it to be.

Quote

Proposing a sensible path forward (see above - you did actually read it all before going onto the defensive didn't you?)


I did read it all, and I dont think I was defensive, I just asked you a couple of questions. I can understand your POV. You want it NOW, not when its ready. I want a lot of things now too, but the world doesn't work that way. We have to work hard for the things we want.

Proposing a 'sensible path forward' does what exactly? what does that achieve? nothing... in open source, code is what counts, being the guy with the big idea doesn't really mean squat.

AROS only has a small set of developers. If you fork it, how many folks do you think will work on the classic side? how many on the future side? Will it take twice as long to get anywhere with half the developers?

What would this 3.1classic compatible AROS bring that genuine 3.1 doesn't? You can still get 3.1 on amiga forever cd so its not like its unavailable.

Why dont you start an arch/m68k-amiga port in aros, because, that would get you off and going with the whole 'classic' piece that you want. Once you get that compiling you should be able to drop in all the libs and other bits as replacements.

I do like the idea of a 'future' version, Id love to see an L4 kernel driving it, make use of that mmu, a much better filesystem, etc.

I'm trying to get aros working on the efika. I dont care about classic hardware or classic binary compat. I would love to see a jittable emulation layer that translates api calls across from m68k apps into native code. But I dont  really see your 'classic' view point of 100% drop in binary compat and replacing wb3.1. You really need to explain your classic idea and sell it coz I dont see the point of it. If genuine 3.1 wasnt available, then I could maybe see a point to it.

The way I see it, AROS now is the start of your 'future'. The 3.1API is a nice API to start with, its well defined and understood for app developers. I'm very much with Rob on his views.

--/\\-[ Stu ]-/\\--
Commodore 128DCR, JiffyDOS, Ultimate 1541 II, uIEC/SD, CBM 1902A  Monitor
 

Offline yakumo9275

  • Sr. Member
  • ****
  • Join Date: Jun 2008
  • Posts: 301
    • Show all replies
    • http://mega-tokyo.com/blog
Re: How to move AROS forward
« Reply #2 on: July 25, 2008, 09:08:35 PM »
the problem with mac minis for morphos if they do it, 1 - the stock mini has barely any video ram onboard (some models 32mb some 64mb), and upgrading that is a nightmare,sice you cant just stick in a pc agp card, you need one with a mac bios (afaik...). different cards manufacuters use different ram chips so a mac compat bios is not often easy to get etc.





--/\\-[ Stu ]-/\\--
Commodore 128DCR, JiffyDOS, Ultimate 1541 II, uIEC/SD, CBM 1902A  Monitor
 

Offline yakumo9275

  • Sr. Member
  • ****
  • Join Date: Jun 2008
  • Posts: 301
    • Show all replies
    • http://mega-tokyo.com/blog
Re: How to move AROS forward
« Reply #3 on: July 26, 2008, 02:04:34 AM »
Quote
Piru wrote:
Excuse me but where exactly are you going to plug this AGP card?


dang, it all says it has a 4x compatible agp... but I guess its still inbuilt :( mybad. i'll leave this post for posterity :) i see it inbuilt on the underside of the motherboard
--/\\-[ Stu ]-/\\--
Commodore 128DCR, JiffyDOS, Ultimate 1541 II, uIEC/SD, CBM 1902A  Monitor
 

Offline yakumo9275

  • Sr. Member
  • ****
  • Join Date: Jun 2008
  • Posts: 301
    • Show all replies
    • http://mega-tokyo.com/blog
Re: How to move AROS forward
« Reply #4 on: July 28, 2008, 07:30:39 PM »
Quote
HenryCase wrote:
I would like to pick up on one point which has been stated by you both in the past, which is that there isn't a way to distinguish between instructions and data.

They are right, there isnt.

Quote
In my admittedly limited understanding of the subject that seems like complete tosh, so forgive me whilst I persist with my questioning to discover who is mistaken.


You lack a basic fundamental understanding of how a cpu operates, so this thread goes around in circles when people say no, you say yes.

Quote

According to Wikipedia, the following four steps are used in classical CPU architecture: fetch, decode, execute, writeback. The second step 'decode' is of interest to us here. Again, according to Wikipedia:
.....
So for even the most basic program to function the CPU must know the difference between the opcode part of the instruction and the operand part of the instruction. Can we agree on that at least?


The cpu does know the difference between the opcode bits and other bits of the bytes it loads. The problem is that the cpu just loads a stream of bytes into its decoder. it looks at the bits and says mmm these 5 bits mean xor... I'll go run the XOR opcode. it doesnt know what its decoded is a string of text. It loads whatever the instruction pointer is pointing at. If things get really bad, it throws an exception.

--/\\-[ Stu ]-/\\--
Commodore 128DCR, JiffyDOS, Ultimate 1541 II, uIEC/SD, CBM 1902A  Monitor
 

Offline yakumo9275

  • Sr. Member
  • ****
  • Join Date: Jun 2008
  • Posts: 301
    • Show all replies
    • http://mega-tokyo.com/blog
Re: How to move AROS forward
« Reply #5 on: July 28, 2008, 08:08:11 PM »
Quote
HenryCase wrote:
"I'll go run the XOR opcode", so in other words I'm right.

The CPU has the ability to recognise an XOR opcode, and every other opcode it uses, and if part of an instruction isn't an opcode it is data. Therefore a CPU knows, after the 'decode' process, what is an opcode and what is an operand, correct? This requires just a yes or no answer.


Sure it knows, this is how emulators like EUAE run.

x86 for example, uses all 256 'bytes' as master opcodes. That means 'A' is an opcode and 'B' and 'C' and 'a' and 'q' etc. EG: "Edgar Allan Poe" is it text or is it data? Could be valid as both, or one or the other. You cant arbitrarily lable it as either.

Back to your example, say on powerpc, XOR is encoded with 5 bits, so after the 'decode' process, the 5bit XOR opcode is out, the processor is left with 26bits.. only they are not data, its still the same opcode. (all ppc instructions are 32bits).

The problem is, code and data are ambiguous, they are the same thing. There is no rule that says code can not be data or data can not be code in a binary image. The processor _assumes_ its code.

I can see this is fruitless so I'm going to stop replying. I hereby agree with all you say, you are correct, we are all ignorant. Yes memory protection is so easy to add to amiga os, we can trap pointers, detect valid opcodes in a sea of data, magically understand self modifying code and can beat gary kasparov at mahjong with our eyes closed!

I'm done, stick a fork in me.

--/\\-[ Stu ]-/\\--
Commodore 128DCR, JiffyDOS, Ultimate 1541 II, uIEC/SD, CBM 1902A  Monitor