[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Asm or C (was: Re: New Web browser for MiNT)



> The main (only?) points where asm would be even noticably faster than
> C would be some bit operations (like roll) and a few other things which
> aren't mapped to C.

GCC is actually supposed to use rolls, but I have never tried that.
I'd guess it can easily be fooled if you don't write things in the way it
expects, though.

> easier in /high level/ languages).  Btw.  I saw in Python language
> newsgroup a very short example (fibonacci series) of how much a good
> algorithm may be faster than a naive one.  Naive one was longer and more
> than *10* times slower...  I wish I would have saved them :-(.

Hmm, a naive fibonacci routine is usually shorter. You wouldn't be able
to put a number on the speedup with a smarter routine, though, since it's
a case of different computation complexity (I'm too tired to check right
now, but it could well be a case of linear vs exponential time).

Here are three fibonacci routines from my CLFL example program:  ;-)

-- This is the naive one
fib1 n = if n <= 1 then n
         else fib1 (n - 1) + fib1 (n - 2);

-- A tail recursive version
-- More or less the same as a normal iterative solution
-- CLFL currently has no 'tuples' so this uses a list instead
fib2 n =
   let fib n x:y:nil =
          if n == 1 then y
          else fib (n - 1) [y, x + y]
   in if n then fib n [0,1]
      else 0;

-- Mostly an example of mutual recursion in a CLFL function
-- If you can understand this, you should be proud of yourself  ;-)
fib3 x =
   let    from n     = n : from (n + 1),
          nth x:xs n = if n == 1 then x
                       else nth xs (n - 1)
   letrec fiblist = 1 : 1 : map fib (from 2),
          fib n   = nth fiblist n + nth fiblist (n - 1)
   in fib (x - 1);

A couple of short notes:
x : xs   x is the first element in a list and xs is the rest of the list
nil      an empty list
[1,2,3]  The same as  1:2:3:nil
map      A function that applies a function to all elements in a list.
         Often predefined in functional languages, but it's easy to write
         one yourself (it's not built into CLFL).
let      Define some local functions.
letrec   The same, but can deal with mutually recursive functions.
in       Here comes the actual function in case there were local definitions.

> > If you find it so difficult to push a few values on the stack, why don't
> > you write a macro for it?
> 
> MIT syntax used by GCC takes some accustoming...

I guess we could try to make the next GCC port use the standard syntax.
I actually built a cross compiler from the latest (two weeks old) EGCS (an
experimental GCC version) sources yesterday and got something that looked
almost normal out of it (probably depending on the target I chose). There
were some strange '%' characters before all the register names, though...

I've not tried GCC 2.8, but EGCS 1.02 produced noticeably better code than
GCC 2.7.2.2 for my two (very small) test programs.

> Btw.  Is there somewhere a doc on how to use inline assembler with gcc?

Yes. I believe it's somewhere among all the GCC .info files.
You should be able to find them at Cygnus ftp site for example.

> Err... I doubt that functional languages are very intuitive for beginners.

I guess it depends on what kind of beginners you're talking about.
Functional languages are very much like mathematics, which hopefully (for
their own sake!) is well suited for people who are studying for an MSc degree.

> I'd rather recommend some dynamically bound/typed object oriented language
> like python (its orthogonality guides users naturally to modular program
> design (yeah, I love clauses like that <g>).

I've not yet got around to trying Python out, unfortunately.

> > Perhaps I should release CLFL (compiled lazy (or C-like) functional language,
> > the one I mentioned above) so that the Atari people can see the light.  ;-)
> 
> Yep. :)

If anyone's really interested, please get in touch with me.
The example code above should give you some kind of idea what it's all about.

There's no way CLFL can be used to write actual applications, but functional
languages can be really nice for trying out algorithms, for example.
Input/output is not really something that fits very well into the functional
programming paradigm, but there are ways around that.

> > Unfortunately, the current implementation of CLFL is untyped and has no
> > garbage collection, so it's still possible to run into serious trouble.  :-(
> 
> More fun...  Does it use ref counting?  It's more portable than GC. :)

Since CLFL currently doesn't support user defined data types, it's more or
less necessary for it to be untyped. That way one can fake data types by
creating really strange lists and extracting the various elements using
pattern matching.

Reference counting is one way to implement garbage collection (I actually
use that in the compiler itself), but for something like CLFL it's not needed.

-- 
  Chalmers University   | Why are these |  e-mail:   rand@cd.chalmers.se
     of Technology      |  .signatures  |            johan@rand.thn.htu.se
                        | so hard to do |  WWW/ftp:  rand.thn.htu.se
   Gothenburg, Sweden   |     well?     |            (MGIFv5, QLem, BAD MOOD)