Windows OS on PSP

[TheHeadFL]

Its talking about emulating an x86 type system. Anytime you are running an emulation, you want it to run as fast as possible. Especially on limited hardware. In this case, it would've even probably benefited them to write a good portion of it in native assembly.

EDIT: nvm, I misread. I thought that Movitz was something that those people were running Linux and Windows *on top of*.

 

[uzi9mm]

what is lisp, it is like you guys are speaking a different language......... lol

 

[TheHeadFL]

I am sure furtive felon has a better explanation, but unless anything has changed, LISP is short for List Processor, which is a computer programming language.

It is unlike C/C++/Java/etc, however, in that it is a "functional" language, whereas the others are mostly "imperative" languages. The reason why I remarked that it must be slow is because LISP, being functional, is ill-suited for the Von Neumann architecture, which is inherently imperative.

Functional programming - All recursive, usually not in a preset order
Imperative programming - One statement after another in some defined order

Here is a good example of a simple LISP function:

Union Two Sets together:

(defun union (x y)
     (cond ((null x) y)
          ((member (car x) y)  (union (cdr x) y))
          (T (cons (car x)  (union (cdr x) y))
     )
)

In C++ you might do the following (non-recursive solution off the top of my head):

int* union(int* set1,int size1, int* set2, int size2)
{
   int c,i;
   int marker=0;
   if (size1<0) return null;
   if (size2<0) return null;
   int *merged = new int[size1+size2];
   int mergesize=size1+size2;
   int *result;
   // Merge two sets
   for (c=0;c<size1;c++)
   {
      merged[c]=set1[c];
   }
   for (c=0;c<size2;c++)
   {
      merged[c+size1]=set2[c];
   }
   // Determine number of unique members
   for (c=0;c<mergesize-1;c++)
   {
      for(i=c+1;i<mergesize;i++)
      {
         if (merged[c]==merged[i]) break;
      }
      if (i != mergesize) continue;
      else 
      {
         marker++;
      }
   }
   // Create correctly sized result set
   result = new int[marker];
   marker=0;
   // Fill result set ensuring no duplication (sets do not by definition have duplicates)
   for (c=0;c<mergesize-1;c++)
   {
      for(i=c+1;i<mergesize;i++)
      {
         if (merged[c]==merged[i]) break;
      }
      if (i != mergesize) continue;
      else 
      {
         result[marker]=merged[c];
         marker++;
      }
   }
   return result;
}

 

[furtivefelon]

erm, though some dialect of lisp is favorably recursive (scheme comes to mind), Common Lisp you can use iterative approach, with an arguably more powerful macro to handle iterative algorithm than say C++'s while/for/do...while.

However, there is something in lisp called Tail Recursion, where it looks uglier than pure recursion, but it will run at the same speed as iterative approach in 99% of the cases, as compiler optimized for tail recursion will in the end convert the tail recursive algorithm into iterative algorithm..

from your previous example (assuming both works), you can of course see another adventage of lisp, that lisp code is easier to read purely because of it's shortness, which is the basis of code reuseablity and security, with a touch of elegance.. excluding the last two end brackets (in lisp community, we don't line up brackets because that's editor's job to match brackets), would you rather read 4 lines of code or would you rather read 40 lines of code (i didn't count)..

 

[TheHeadFL]

The problem is that the vast majority of problems in computer science do not lend themselves to recursive solutions. Thus defeating the advantage or purpose of using a functional language.