Free Eiffel under GPL 
Author Message
 Free Eiffel under GPL

SmallEiffel version -0.97 is now available.
Most of reported bugs have been corrected.
Version -0.97 has done significants progress comparing to
the previous version :
   - inside of the compiler cleaned (compiler is smaller
   and run faster),
   - precomputing of once function (only when it is possible :-),
   - universal container class COLLECTION is now in the standard
   library (actual sub-class are ARRAY, FIXED_ARRAY and LINK_LIST).
   - added class FIXED_ARRAY (like ARRAY, but the lower bound is
   frozen to 0 to run a little bit faster as one can do it in C),
   - added class LINK_LIST (classic one way linked list),
   - added the "finder" command to locate class on the disk,
   - and a lot of other good stuff :-)

Enjoy SmallEiffel.

Here is the READ_ME file of SmallEiffel :
------------------------------------------------------------------------
-- Part of SmallEiffel -- Read DISCLAIMER file -- Copyright (C)

--
-- SmallEiffel is not Smalltalk.                 D.Colnet 10/2/94
-- Is it still Eiffel ?
--
1 - What is SmallEiffel ? -
SmallEiffel is a free Eiffel compiler distributed under the
terms of the GNU General Public License as published by the
Free Software Foundation.
You can download SmallEiffel at :

   ftp://ftp.loria.fr/pub/loria/genielog/SmallEiffel

2 - Brief Description of SmallEiffel -
SmallEiffel is the fruit of a research project done at CRIN
(Centre de Recherche en Informatique de Nancy). SmallEiffel is
already used by students of the University Henri Poincare'
at Nancy (FRANCE).
We are using Eiffel as a first langage for teaching OOP
since 1990 (SmallEiffel is used since september 1995).

SmallEiffel is already portable on UNIX, Linux, BSD, HP-UX,
IRIX, XENIX, DOS and OS2. SmallEiffel will be soon available
on WINDOWS 95 and Macintosh.

Current distribution includes a compiler (command 'compile'),
a pretty printer (command 'pretty') and other tools.
An Eiffel interpretor will be added to the distribution
in a few months (3 or 4 months).

3 - Contents of the SmallEiffel directory -

3.1 - directory misc : Miscellaneous files including the
      INSTALL file.
3.2 - directory man : Miscellaneous help files.
3.3 - directory bin : The binary place including the `compile'
      command.
3.4 - directory bin_c : C source code for tools of bin directory.
3.5 - directory lib_std : Standard Eiffel Library (string.e,
      integer.e, general.e, array.e, ...).
3.6 - directory lib_show : Demonstration and examples Eiffel
      programs.
3.7 - directory lib_test : Set of program to tests SmallEiffel
      (see also directory misc/self_test).

4 - Bug Report -
Thank in advance for bug reports. Don't forget to have a look
first in the misc/NOT_YET_IMPLEMENTED file.
Please, try to isolate the bug as much as possible.
The best is to be able to create a single file, as small a
possible (which include the bug).




Mon, 19 Oct 1998 03:00:00 GMT  
 Free Eiffel under GPL

Quote:

>   - added class FIXED_ARRAY (like ARRAY, but the lower bound is
>   frozen to 0 to run a little bit faster as one can do it in C),

How do you do this? As far I remember C arrays are fixed, so you can
access them with:
   - load rx, index
     load ra, base (rx)    -- element in ra ....

   I wonder how you make it a little bit faster.

About dynamic arrays: I wonder how a lower limit of 0 makes access
faster. At least up to now nobody could tell me why any other lower
(or upper) limit is slower - in my opinion it does not matter if the
ZERO element is in fact occupies the first element of the array or (as virtual
element) is at any other place.  You have to add the index and the pointer
to the ZERO element. Thats all (at least I thought so).

But, I am ready to learn !! (I understand if you will hide your secrets
to the competition - but I will look in the code ;-)

BTW, if you send a floppie again, we will also put the new version on the
SIG Eiffel CD -- ftp is still very slow !

--
 _____________/        Frieder Monninger       D-35619 Braunfels-Altenkirchen

      >-\_______________)



Sat, 24 Oct 1998 03:00:00 GMT  
 Free Eiffel under GPL


|> >
|> >   - added class FIXED_ARRAY (like ARRAY, but the lower bound is
|> >   frozen to 0 to run a little bit faster as one can do it in C),
|> >
|> How do you do this? As far I remember C arrays are fixed, so you can
|> access them with:
|>    - load rx, index
|>      load ra, base (rx)    -- element in ra ....
I am using C ... not Assembly langage ;-)
|>
|>    I wonder how you make it a little bit faster.
|>
There is no secret at all.
The lower bound of a FIXED_ARRAY is always frozen to 0 (unlike ARRAY).
Thus, when frozen to 0, you don't need to increment the base of access.

Here is the definition of SmallEiffel ARRAY.item :


      do
         c_inline_c("R=(C->_storage)[a1-(C->_lower)];")
      end;

And here is the SmallEiffel FIXED_ARRAY.item :


      do
         c_inline_c("R=(C->_storage)[a1];")
      end;

Note that you don't have to look in the C code, because of the
SmallEiffel c_inline_c special procedure :-)

FIXED_ARRAY and ARRAY both inherit of COLLECTION.
And here is the SmallEiffel COLLECTION.item


         -- Item at position `index'.
      require
         inside_bounds: valid_index(index)
      deferred
      end;

|> About dynamic arrays: I wonder how a lower limit of 0 makes access
|> faster. At least up to now nobody could tell me why any other lower
|> (or upper) limit is slower - in my opinion it does not matter if the
|> ZERO element is in fact occupies the first element of the array or (as virtual
|> element) is at any other place.  You have to add the index and the pointer
|> to the ZERO element. Thats all (at least I thought so).
You are right ... and I am wrong :-(
I can memorize the virtual 0 adress for an ARRAY.
If I don't need to add an attribute to ARRAY, il will probably remove the FIXED_ARRAY
class (you are right : ARRAY can run has fast as FIXED_ARRAY :-).

|>  
|> But, I am ready to learn !! (I understand if you will hide your secrets
|> to the competition - but I will look in the code ;-)
No. I don't :-)
|>
|> BTW, if you send a floppie again, we will also put the new version on the
|> SIG Eiffel CD -- ftp is still very slow !
Don't loose too much time to get -0.97 Version because I will release
soo the -0.96 Version (a stupid bug makes the -0.97 version unusable
on BSD like systems).

Thanks.

D.Colnet



Sun, 25 Oct 1998 03:00:00 GMT  
 Free Eiffel under GPL

Quote:


> >   - added class FIXED_ARRAY (like ARRAY, but the lower bound is
> >   frozen to 0 to run a little bit faster as one can do it in C),

> How do you do this? As far I remember C arrays are fixed, so you can
> access them with:
>    - load rx, index
>      load ra, base (rx)    -- element in ra ....

>    I wonder how you make it a little bit faster.

> About dynamic arrays: I wonder how a lower limit of 0 makes access
> faster. At least up to now nobody could tell me why any other lower
> (or upper) limit is slower - in my opinion it does not matter if the
> ZERO element is in fact occupies the first element of the array or (as virtual
> element) is at any other place.  You have to add the index and the pointer
> to the ZERO element. Thats all (at least I thought so).

The difference in a dynamic array is that the lower boundary is
moveable. Either the data has to move when the lower bound is adjusted
or each array access has to, effectively, calculate the address of the
zero element. I haven't hacked around in the generated C that much to
find out which approach current compilers use, but I don't see any way
in which you can avoid either the move or the additional offset
calculation.

BTW I might have inadvertantly libelled SIG Eiffel in another post by
claiming that it used external routines in all circumstances for all
ARRAY access. I'm sorry, I looked at the non optimised code and at the
class definition and made the assumption.

Bill Williams
--
Bill Williams                     |GEC-Marconi does not necessarily
GEC-Marconi Research Centre       |endorse my opinions!


Tel: +44 1245 242016
Fax: +44 1245 242003



Sun, 25 Oct 1998 03:00:00 GMT  
 Free Eiffel under GPL


|> >
|> >   - added class FIXED_ARRAY (like ARRAY, but the lower bound is
|> >   frozen to 0 to run a little bit faster as one can do it in C),
|> >
|> How do you do this? As far I remember C arrays are fixed, so you can
|> access them with:
|>    - load rx, index
|>      load ra, base (rx)    -- element in ra ....
|>
|>    I wonder how you make it a little bit faster.
|>
|> About dynamic arrays: I wonder how a lower limit of 0 makes access
|> faster. At least up to now nobody could tell me why any other lower
|> (or upper) limit is slower - in my opinion it does not matter if the
|> ZERO element is in fact occupies the first element of the array or (as virtual
|> element) is at any other place.  You have to add the index and the pointer
|> to the ZERO element. Thats all (at least I thought so).
Yes, (one more time), you are right ... and I am wrong :-(

But, we must also consider the 2 followings arguments :

1/ Yes it is theorytically possible to compute the virtual address (of element
T[0}), and thus it is possible to memorize this virtual adress to avoid
computation at each access.
But, there is still a problem when address is really virtual (too big or too small),
suppose it gives you a negative address ! Is it possible to have portable ANSI C
doing this ?
I am not sure. If you are able to write portable ANSI C to compute every
possible virtual origin, let me know.

2/ As SmallEiffel is doing Type Inference, in some case it is possible for SmallEiffel
to know that the array you are using is a FIXED_ARRAY (and not an ARRAY).
When SmallEiffel is sure of this, lower is automatically inlined as 0 (using mode -boost
of SmallEiffel).
When you are looping on a FIXED_ARRAY, going to the lower bound, the benefit is evident.
The stop condition is very simple ( index < 0 ).
I have already added a new benchmark in SmallEiffel/lib_show/bench2/ to show the
gain (this benchmark will be part of the -0.96 Version of SmallEiffel).

Waiting the -0.96 version to be released, I put here the new benchmark :

On the same machine, it gives :

        compile array_bench2 make -boost -o array_bench2
        /bin/time array_bench2
        4.0 real         1.9 user         0.3 sys  
        compile fixed_array_bench2 make -boost -o fixed_array_bench2
        /bin/time fixed_array_bench2
        5.3 real         1.7 user         0.3 sys  

Yes it is NOT a big gain ... but adding option -O3 gcc :

        compile array_bench2 make -boost -o array_bench2 -O3
        /bin/time array_bench2
        1.1 real         0.6 user         0.4 sys  
        compile fixed_array_bench2 make -boost -o fixed_array_bench2 -O3
        /bin/time fixed_array_bench2
        0.8 real         0.4 user         0.3 sys  

FIXED_ARRAY run 50% faster as ARRAY on this (oriented benchmark :-).
Note that for SmallEiffel/lib_show/bench1 the benefit is null !

Here is the full code of SmallEiffel/lib_show/bench2 :

deferred class BENCH2
--
-- Are FIXED_ARRAY running faster than ARRAY ?
--

feature {NONE}

   cltn: COLLECTION[INTEGER] is
      deferred
      end;

   upper: INTEGER is 900000;

   bench is
      local
         i: INTEGER;
      do
         from
            i := cltn.upper - 1;
         until
            i = cltn.lower
         loop
            cltn.put(cltn.item(i-1),i);
            i := i - 1;
         end;
      end;
end

class ARRAY_BENCH2

inherit BENCH2;

creation make

feature

   cltn: ARRAY[INTEGER];

   make is
      do
         !!cltn.make(0,upper);
         bench;
      end;

end -- ARRAY_BENCH2

class FIXED_ARRAY_BENCH2

inherit BENCH2;

creation make

feature

   cltn: FIXED_ARRAY[INTEGER];

   make is
      do
         !!cltn.make(upper);
         bench;
      end;
end



Mon, 26 Oct 1998 03:00:00 GMT  
 Free Eiffel under GPL

Quote:
>The lower bound of a FIXED_ARRAY is always frozen to 0 (unlike ARRAY).
>Thus, when frozen to 0, you don't need to increment the base of access.

>Here is the definition of SmallEiffel ARRAY.item :


>      do
>         c_inline_c("R=(C->_storage)[a1-(C->_lower)];")
>      end;

>And here is the SmallEiffel FIXED_ARRAY.item :


>      do
>         c_inline_c("R=(C->_storage)[a1];")
>      end;

I would implement it in both cases on the same way:
1. there must be a structure a_struc anywhere containing a element _storage.
2. I would call it _zero_element and would store the pointer to the element zero
   (which in fact can be everywhere)
3. The value of this entry can be changed when the array is resized -
   exactly as it works in SMallEiffel when the array is resized.
4. the code would look like:

Quote:

>      do
>         c_inline_c("R=(C->_zero_element)[a1];")
>      end;

This technique is not very new, it was used even in Algol60 compilers.


Thu, 29 Oct 1998 03:00:00 GMT  
 Free Eiffel under GPL


Quote:
> 2. I would call it _zero_element and would store the pointer to the element
> zero    (which in fact can be everywhere)

I think this (or something equivalent) is the intended technique.  
However, it won't work if addition isn't strictly commutative and  
associative, *including overflows*.
I.e. if the _zero_element pointer is negative, how does the processor  
react? I can easily imagine machines with that don't allow a negative  
address in a base register. I know this is not a problem on the 68x00  
architecture, but I'm not so sure on 80x86.
Plus possible incompatibilities among C compilers... I think the issue  
is very real. I don't know if ANSI C defines this situation; but even  
it did, I'd expect that at least some C compilers don't conform in  
such an {*filter*} case.

-Joachim

--
Looking for a new job. Resume available on request.



Thu, 29 Oct 1998 03:00:00 GMT  
 Free Eiffel under GPL

Quote:


> > 2. I would call it _zero_element and would store the pointer to the element
> > zero    (which in fact can be everywhere)

> I think this (or something equivalent) is the intended technique.  
> However, it won't work if addition isn't strictly commutative and  
> associative, *including overflows*.
> I.e. if the _zero_element pointer is negative, how does the processor  
> react? I can easily imagine machines with that don't allow a negative  
> address in a base register. I know this is not a problem on the 68x00  
> architecture, but I'm not so sure on 80x86.

An address is only 'negative' if the CPU chooses to interpret it as a
*signed* number. I don't know of any CPU where addresses are
interpreted as signed. It's not a sensible concept (as you point out
yourself). I think your concern is a red-herring. The CPU interprets a
bit pattern as a bit pattern. Provided no exceptions are raised when
an offset calculation overflows I can't see where any problems would
arise. On the 80x86 the main problems arise at 64k boundaries in 286
compatibility mode, not at the -1,0 boundary.

Quote:
> Plus possible incompatibilities among C compilers... I think the issue  
> is very real. I don't know if ANSI C defines this situation; but even  
> it did, I'd expect that at least some C compilers don't conform in  
> such an {*filter*} case.

The whole point about C (even ANSI C) is that if you want to work at
the bit pattern level, it lets you. In this sense, C is a high level
assembler. If a C compiler automatically and unconditionally generated
exception code for me I'd be seriously unhappy (how would you write
pseudo-random number generators for example, or code some of the
cyclic code generation algorithms?).

Quote:
> -Joachim

Bill
--
Bill Williams                     |GEC-Marconi does not necessarily
GEC-Marconi Research Centre       |endorse my opinions!


Tel: +44 1245 242016
Fax: +44 1245 242003



Sat, 31 Oct 1998 03:00:00 GMT  
 Free Eiffel under GPL

Quote:

> An address is only 'negative' if the CPU chooses to interpret it as a
> *signed* number. I don't know of any CPU where addresses are
> interpreted as signed. It's not a sensible concept (as you point out

On 68000, addresses are signed, in the sense that when you use a 16-bit  
address, it is sign-extended to 32-bit before use. Thus we can access to two  
blocks of memory with only 16 bits : 00000000-00007ffff and ffff8000-ffffffff.


Thu, 05 Nov 1998 03:00:00 GMT  
 Free Eiffel under GPL

Quote:


> > An address is only 'negative' if the CPU chooses to interpret it as a
> > *signed* number. I don't know of any CPU where addresses are
> > interpreted as signed. It's not a sensible concept (as you point out

> On 68000, addresses are signed, in the sense that when you use a 16-bit  
> address, it is sign-extended to 32-bit before use. Thus we can access to two
> blocks of memory with only 16 bits : 00000000-00007ffff and ffff8000-ffffffff

OK, I take your point, I'd forgotten this particular 'address mode' on
the 68000 but I pose this question:

If you load the 16 bit address 0x7FFF into an address register and
execute a postincrement instruction ie. the assembler equivalent of
the C *p++, what is the new address? 0x00080000 or 0x00000000? The
answer, of course, is the former (flame on - we're talking proper
CPU's here, not Intel x86 - flame off :-). In other words, the
increment operation is performed on the unsigned number. Similarly, if
the 16 bit address 0x8000 is loaded and sign extended to 0xFFFF8000
and then a predecrement operation is performed (ie. *--p) what address
is used? 0xFFFFFFFF or 0xFFFF7FFF? Obviously it is the latter. It's a
matter of interpretation of course, but in my view the 68000 does use
unsigned arithmetic for address calculations (although, since the bit
patterns end up the same way in the 32 bit registers its a moot
point).

BTW, apologies to all for wandering so far from the original thread.

Bill
--
Bill Williams                     |GEC-Marconi does not necessarily
GEC-Marconi Research Centre       |endorse my opinions!


Tel: +44 1245 242016
Fax: +44 1245 242003



Sun, 08 Nov 1998 03:00:00 GMT  
 Free Eiffel under GPL


Quote:
> An address is only 'negative' if the CPU chooses to interpret it as  
a
> *signed* number. I don't know of any CPU where addresses are
> interpreted as signed. It's not a sensible concept (as you point out
> yourself).

Agreed. But the issue is not machine architecture, but the  
implementation of C compilers on strange machine architectures.

To be more specific: the base address may be negative. If the C  
compiler is instructed to handle addresses as unsigned, it is fully  
free to interpret a negative base address as zero, a random number, or  
to blow up the computer. If the C compiler is instructed to handle  
addresses as signed, the same problem may occur at the end of the  
first half of the address space.

Usually, this is not a problem. Most current CPUs (including 68K and  
80c86) have two's complement arithmetic, which is associative and  
commutative even in the presence of overflows and underflows, and C  
compilers gladly make use of this. Other machines are not so good-
natured, and I'm not sure what the code generated by a C compiler will  
do on such machines.

Quote:
> I think your concern is a red-herring.

Sorry that I have to disagree. It may be for you, but it certainly is  
not for me (I wouldn't have raised the issue if it weren't).

Quote:
> Provided no exceptions are raised when
> an offset calculation overflows I can't see where any problems would
> arise.

But that's exactly the point. The 86K and 80x86 machines don't raised  
exceptions and don't truncate on over-/underflows, but other machines  
might, and a C compiler doesn't care about it.
Just think about the Java Virtual Machine. I don't think it will be  
happy with address underflows. And porting Eiffel to the JVM is  
nothing that I'd call far-fetched.

Quote:
> assembler. If a C compiler automatically and unconditionally generated
> exception code for me I'd be seriously unhappy (how would you write
> pseudo-random number generators for example, or code some of the
> cyclic code generation algorithms?).

Oh, I'd use an assembler language (high level or low level, whatever  
is available). And I'd consider C code for such random-number or CRC  
algorithms nonportable, in the sense that I'd check that code whenever  
I had to port it to a new machine architecture or a new C compiler.  
(Though I'd probably do the code in the same way as you do <g>.)

-Joachim

--
Looking for a new job. Resume available on request.



Fri, 13 Nov 1998 03:00:00 GMT  
 
 [ 15 post ] 

 Relevant Pages 

1. SQL Rdd for clipper, opensource, gpl, or free

2. gbeta v0.5 released - free (g)BETA interpreter (GPL)

3. Free BETA interpreter (GPL) -- problem fixed

4. New, free BETA interpreter (GPL)

5. gbeta v0.5 released - free (g)BETA interpreter (GPL)

6. Free BETA interpreter (GPL) -- problem fixed

7. New, free BETA interpreter (GPL)

8. _Free_ Eiffel 4 Windows vs _ _ Eiffel for Linux

9. New free Eiffel compiler

10. Links Related To comp.lang.eiffel - FREE ACCESS 0228

11. Visual Eiffel for Windows available for free

12. Links Related To comp.lang.eiffel - FREE ACCESS 0226

 

 
Powered by phpBB® Forum Software