Subject: [clisp-list] cygwin

From: lin8080 <[email-masked]>
Date: Sat Apr 27 20:02:02 2002

Well. Going to: 

http://www.cygwin.com/

and find this on the side-top: (also there is the dll to do list)
......................................

Cygwin is a UNIX environment, developed by Red Hat, for Windows. It
consists of two parts: 

 - A DLL (cygwin1.dll) which acts as a UNIX emulation layer providing
substantial UNIX API functionality. 

 - A collection of tools, ported from UNIX, which provide UNIX/Linux
look and feel. 

 The Cygwin DLL works with all non-beta versions of Windows since
Windows 95, with the exception of Windows CE. 
......................................

Note: ...exception Windows CE !! And you know, every year a new window
issue (means an other dll). 

Is Cygwin a kind of a hype? At least you shipp this *.dll with the
clisp-stuff. Before doing so, I vote for simple gfx inside the
clisp-files.

stefan

---

From: Randall R Schulz <[email-masked]>
Date: Sat Apr 27 21:16:01 2002

Stefan,

"Is Cygwin a kind of hype?" You've got to be kidding.

Cygwin is not hype, is not over-sold in being called a Unix environment. It 
is very powerful and very complete. People have ported all sorts of Unix 
software, including some very large projects such as Emacs,  the TeX Suite, 
Apache Web Server, Python,Perl, etc, autoconf and automake, gcc/g++, gdb, 
BASH, TCSH, Ash and everything on "down" to cat and a large complement of 
libraries.

Cygwin is under continuing development and the set of contributed packages 
continues to increase.

I don't know what you mean by "vote for simple gfx inside the clisp-files." 
What is the issue about which you purport to be voting?

Also, I'm uncertain about what you mean by your statement about shipping a 
DLL with CLISP. Cygwin is not some kind of add-on. It is an environment in 
a very real sense. Software must be compiled (and sometimes ported, usually 
only minimally) for the Cygwin environment. Binaries built for / with 
Cygwin minimally require the Cygwin1.dll to be available when they are run.

Cygwin is an open-source project distributed under GPL, so if you publish 
software that uses Cygwin, you must take responsibility for making Cygwin 
sources available, too.

It would be very foolish to write off Cygwin as irrelevant to CLISP. Since 
the Windows APIs are so different than those used in Unix (any variant), 
having Cygwin opens up a huge range of software written for the Unix / 
Linux / POSIX APIs that would otherwise require a great deal of work to 
port to Windows.

For example, I was able to adapt the Unix port of the Glimpse indexer by 
adding a very few very trivial patches.

Learn about Cygwin before you disparage or pooh-pooh it.

Out of curiosity, does CLISP run on Windows CE?

Randall Schulz
Mountain View, CA USA

At 19:32 2002-04-26, you wrote:

>- A collection of tools, ported from UNIX, which provide UNIX/Linux look 
>and feel.
>
>The Cygwin DLL works with all non-beta versions of Windows since Windows 
>95, with the exception of Windows CE.
>clisp-stuff. Before doing so, I vote for simple gfx inside the clisp-files.
>
>stefan

---

From: Stefan Kain <[email-masked]>
Date: Sun Apr 28 12:36:13 2002

BTW,

there are two Stefan's on this list.

I am the one who usually posts via [email-masked],
because lin8080 also has a freenet.de - account, incidently.

Please don't mix it up. :-) 

I am innocent! 

Please distinguish us by adding some additional info.

stefan [lin8080], that's the one who doesn't know cygwin

and

Stefan [smk], that's me, the brave german-comment-translator... :-)

---

From: Darryl Okahata <[email-masked]>
Date: Mon Apr 29 10:43:07 2002

> Out of curiosity, does CLISP run on Windows CE?

     Going off on a slight tangent, CLISP can be made to run on a Sharp
Zaurus (a recently-released color PDA running Linux).  It's a very
tedious and manual process (configure can't be used as-is because a
cross-compiler is used), but it's possible.  A different port of CLISP
was used to get maxima running on the Zaurus.

[ Well, technically, it should be possible to compile CLISP natively on
  the Zaurus, using configure, but I've been too lazy to hunt down and
  install all of the native tools necessary to do it (e.g., gcc).  ]

-- 
	Darryl Okahata
	[email-masked]

DISCLAIMER: this message is the author's personal opinion and does not
constitute the support, opinion, or policy of Agilent Technologies, or
of the little green men that have been following him all day.

---

From: Stefan Kain <[email-masked]>
Date: Mon Apr 29 12:42:57 2002

Hi,

Dan Stanger wrote:
> BTW, how is your clisp compiler outputting c code going?

Yes, put salt into my wounds! :-)

After a couple of hours stepping through a call of (compile 'square)
(Now guess, how square is defined...),
I have found the very function that emits the bytecode: 
assemble-LAP in compiler.lisp.
(Applause!!)  I don't know, what LAP stands for, but maybe Bruno can
shed some light on this naming.

After this very exciting discovery, I have thoroughly studied the
C-function
interpret_bytecode_ in eval.d
which encodes all the bytecode actions in C in a huge

switch(*byteptr++) { ...lots of cases, one for each  bytecode... }
statement.

The bytecode interpreter defined by this statement interpretes the code
literally byte for byte. What I want to do is: Instead of executing each
case-statement for the respective bytecode, write the C-encoding to a
file plus augmenting the jump targets with C-labels.

So I copy the function interpret_bytecode_ to a function emit_c_code,

and the case statement for the bytecode do_something:

case do_something:
      { do_it };

becomes:

case do_something:
       fprintf(output_stream, "{ do_it };\n");

for the simple cases.

That's why this is called abstract interpretation, right? :-)

jump-intructions will be sligthly more difficult, because
I will have to identify the jump-destination in the C-code with a
jump-label,
while in the bytecodevector it is only the index in the vector, like
jump to bytecode in position 15 means: byteptr = 15 (tiny
oversimplification...)

in C I will need something like:  goto l15;

Now you might ask: "Where the h..k is the difference between calling
interpret_bytecode
and running a binary produced by this ominous emit_c_code..."

There is almost none, except the lack of interpretative overhead due to
manipulating
byteptr and executing the machine-jumps to the case-statements. 

"Will there be any speed gain?"
Unlikely. If so, I will be truly surprised. The generated object-code
from this C-code
will be significantly larger than the bytecode. 
The instruction cache is usually pretty small.

"Why are you doing this?"
Just for fun.

Please don't laugh too loud behind the stage because I have taken the
risk to announce
my plan before performing in front of the big audience.

If I fail, we all can have a good laugh, anyway.

Bye,
Stefan