Welcome, Guest. Please login or register.

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

Description:

0 Members and 3 Guests are viewing this topic.

Offline Trev

  • Hero Member
  • *****
  • Join Date: May 2003
  • Posts: 1550
  • Country: 00
    • Show all replies
Re: How to move AROS forward
« on: July 29, 2008, 02:55:36 AM »
My two cents re: interpretation of binary data: It's possible to interleave opcodes and operands, where one opcode's operand is actually an opcode itself, and a subsequent jump or branch takes advantage of that fact. This was a common dirty hack in MS-DOS software. You can't assume that every byte (or every bit, even) is either an opcode or an operand. It can be both. Or padding. Or a gamma ray induced parity error. Or an abstract picture of someone's grandmother.

Obviously, that complicates any attempt to map an arbitrarily complex sequence of code. If you do figure out a way to do it optimally in polynomial time, kudos. You'll earn a Fields Medal (if you're under 40 years of age), and the Clay Institute will award you 1,000,000 USD for a generalized solution. Hell, you'd probably earn a Nobel Prize as well. ;-) For all we know, you could be the one who solves this problem. Good luck! Sincerely.

Trev
 

Offline Trev

  • Hero Member
  • *****
  • Join Date: May 2003
  • Posts: 1550
  • Country: 00
    • Show all replies
Re: How to move AROS forward
« Reply #1 on: July 30, 2008, 01:39:53 AM »
Quote
So in an MP protected OS like, for example, FreeBSD, how do instructions/data get passed between applications and kernel?


Memory protection and a distinction between "kernel" and "user" spaces are not dependent upon one another. You can have one without the other.

Some operating environments / operating systems / virtual machines use invalid opcodes and exception handlers to pass data between user and kernel environments or between subsystems. For example, Virtual PC uses opcode 0Fh,0C7h,0C8h and two bytes of data representing the API function to allow guest systems to communicate with the host environment.

The subsystem/sandbox approach is widely implemented in other operating systems, including consumer products, e.g. NTVDM (Virtual DOS Machine) and WoW (Windows on Windows) on 32-bit Windows NT, WoW64 on 64-bit Windows NT, FX!32 on Windows NT/Alpha, many Unixes which allow binaries from other Unixes to run natively, and Amithlon (I'm grossly oversimplifying, but it could be viewed as an Amiga subsystem on Linux).

The problem you're trying to solve is essentially the same one Microsoft solved to allow DOS and 16-bit Windows applications to run on 32-bit Windows NT. They run in either a shared or stand-alone memory space and communicate with the operating system and hardware through a transparent abstraction layer that converts software interrupts and 16-bit Windows API calls to an appropriate 32-bit Windows NT analog.

It's possible for DOS and 16-bit Windows applications to communicate natively with applications and hardware outside their sandbox by using custom modules that expose interfaces on both sides of the wall.
 

Offline Trev

  • Hero Member
  • *****
  • Join Date: May 2003
  • Posts: 1550
  • Country: 00
    • Show all replies
Re: How to move AROS forward
« Reply #2 on: July 30, 2008, 07:19:49 PM »
Part of the problem with a Kickstart replacement is Kickstart itself. Its internals are so well-known that it would be difficult to support a clean room design, especially on a 680x0-based platform.

Of course, you could also argue that the internals are so well-known that it's a de facto standard. The fact that Amiga hardware is no longer commercially available weighs heavily in favor of a new implementation.

Speaking of L4, if Kickstart were reimplemented, it would be very cool to see it done as a hypervisor.

@HenryCase

Don't give up. Binary refactoring (either dynamic or compiler-assisted) isn't a new concept, but it is a young one. Take a look at the literature. The traditional approach of catching exceptions and working around them will work, but it's definitely not as sexy.

Do keep complexity in mind, though. The P versus NP problem is a very real one. As noted, it doesn't take much (around 266 branch instructions or 2^266 combinations) before the number of possible outcomes is more than the approximate number of atoms in the universe (10^80). Really. All you need in that case is a quantum computer with n qubits, where n is the number of branches. ;-)