From mgryan@cruzio.com Tue Feb 15 08:22:03 2011
Return-path: <mgryan@cruzio.com>
Envelope-to: abu@localhost
Delivery-date: Tue, 15 Feb 2011 08:22:03 +0100
Received: from localhost
	([127.0.0.1] helo=software-lab ident=abu)
	by software-lab with esmtp (Exim 4.72)
	(envelope-from <mgryan@cruzio.com>)
	id 1PpFEZ-0005xB-QY
	for abu@localhost; Tue, 15 Feb 2011 08:22:03 +0100
X-Envelope-From: <mgryan@cruzio.com>
X-Envelope-To: <abu@software-lab.de>
X-Delivery-Time: 1297754308
X-UID: 96653
X-RZG-CLASS-ID: mi
Received: from post.strato.de [81.169.145.136]
	by software-lab with POP3 (fetchmail-6.3.18)
	for <abu@localhost> (single-drop); Tue, 15 Feb 2011 08:22:03 +0100 (CET)
Received: from mail.cruzio.com ([63.249.93.182])
	by mailin.webmailer.de (ahmed mi91) (RZmta 25.3)
	with ESMTP id z0069bn1F76u5e ; Tue, 15 Feb 2011 08:18:28 +0100 (MET)
Received: from avalon.cruzio.com (66-53-121-133.stkn.mdsg-pacwest.com [66.53.121.133])
	by mail.cruzio.com with SMTP id p1F7INdF007684;
	Mon, 14 Feb 2011 23:18:24 -0800 (PST)
Message-Id: <201102150718.p1F7INdF007684@mail.cruzio.com>
Subject: PicoLISP portability
To: abu@software-lab.de
Received:  by avalon.cruzio.com; Mon, 14 Feb 11 23:24 PST
Date: Mon, 14 Feb 2011 23:24:51 -0800 (PST)
From: "Mark Ryan" <mgryan@cruzio.com>
Cc: Josef.Bartl@2bartl.de
X-Mailer: ELM [version 2.5 PL6]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: RO
X-Status: A
Content-Length: 1297
Lines: 34

Hello, Alexander Burger,

Thank you for developing PicoLISP and making it available for download.
Have you given any thought to its portability--including to other C
compilers?

For software that is supposed to be "small and lightweight"--I was surprised
to find that PicoLISP includes variables of the 64-bit "long long" type.
Is it possible that you are not aware that many embedded devices do not run
on 64-bit processors, or that this type isn't even part of the latest C++ spec?

PicoLISP includes various other GNU-isms that prevent it from compiling on
other compilers--even those that are compliant with the latest ANSI-C spec.
For example:

	"//" end-of-line comments (which are really not part of the C
	language--they are part of C++ -- as any student should know)

	GNU __attribute__ kludge

	GNU make (not part of either BSD or System V UNIX releases, and
	requires itself and gcc to build).

Many experienced software developers with many years in the industry would
consider it *unprofessional* to write C code that isn't portable to other
compilers.  Just because you and your little net friends all use gcc and
Linux doesn't mean everybody does.

Why make people to waste their time going through your code to fix these
amateurish mistakes?

Sincerely,

Mark Ryan

From abu@software-lab.de Tue Feb 15 08:48:08 2011
Return-path: <abu@software-lab.de>
Envelope-to: abu@localhost
Delivery-date: Tue, 15 Feb 2011 08:48:08 +0100
Received: from localhost
	([127.0.0.1] helo=software-lab ident=abu)
	by software-lab with esmtp (Exim 4.72)
	(envelope-from <abu@software-lab.de>)
	id 1PpFdo-00020Y-KR
	for abu@localhost; Tue, 15 Feb 2011 08:48:08 +0100
X-Envelope-From: <abu@software-lab.de>
X-Envelope-To: <abu@software-lab.de>
X-Delivery-Time: 1297755899
X-UID: 96657
X-Authentication-Results: mailin.webmailer.de (ahmed mi118) (RZmta 25.3)
	header.From=software-lab.de;
	dkim=pass
X-RZG-CLASS-ID: mi
Received: from post.strato.de [81.169.145.136]
	by software-lab with POP3 (fetchmail-6.3.18)
	for <abu@localhost> (single-drop); Tue, 15 Feb 2011 08:48:08 +0100 (CET)
Received: from mo-p00-ob.rzone.de ([81.169.146.162])
	by mailin.webmailer.de (ahmed mi118) (RZmta 25.3)
	with ESMTP id Z00ba0n1F7L12L ; Tue, 15 Feb 2011 08:44:59 +0100 (MET)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1297755899; l=1898;
	s=domk; d=software-lab.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=7xF1anlITT91YYCedyxPRZYd/VE=;
	b=tR8C/tH3GlXkAHmc9Hoo5OJux/8L23kykyfnvgWGTQTIqQRnSFeBoEWCZ1+wFLPk8rj
	QbH2HuZ4o5/Ym8PAxbPZfBlRagenkewqCYvoOc3WertHhOTGOnPeXBdlV1bKsESauF3WW
	nkeZW7CmTL5xrngqouIIZ2UBDz54aPhtcj4=
X-RZG-AUTH: :LW4RVVOnfesGyS0uS7OMacuCIvMeOzH1j5m4YTwauIPRpwlvJMbL6kUgW2vl99q4Eg==
X-RZG-CLASS-ID: mo00
Received: from software-lab (pd9568a7a.dip0.t-ipconnect.de [217.86.138.122])
	by post.strato.de (klopstock mo47) (RZmta 25.5)
	with ESMTPA id K05e67n1F6PoN8 ; Tue, 15 Feb 2011 08:44:59 +0100 (MET)
Received: from abu by software-lab with local (Exim 4.72)
	(envelope-from <abu@software-lab.de>)
	id 1PpFak-0001TP-Uf; Tue, 15 Feb 2011 08:44:58 +0100
Date: Tue, 15 Feb 2011 08:44:58 +0100
From: Alexander Burger <abu@software-lab.de>
To: Mark Ryan <mgryan@cruzio.com>
Cc: Josef.Bartl@2bartl.de
Subject: Re: PicoLISP portability
Message-ID: <20110215074458.GA29615@software-lab.de>
References: <201102150718.p1F7INdF007684@mail.cruzio.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <201102150718.p1F7INdF007684@mail.cruzio.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Status: RO
Content-Length: 1857
Lines: 53

Hi Mark,

thank you for your nice letter.

> Have you given any thought to its portability--including to other C
> compilers?

No.

Though PicoLisp was originally developed on a Mac II in 1988, and at
that time ran on Mac, SCO Unix and MS-DOS, the current version (since
1999) was intended for Linux ONLY.

Why bother about portability of the Language, when you have an OS that
is extremely portable?


> For software that is supposed to be "small and lightweight"--I was surprised
> to find that PicoLISP includes variables of the 64-bit "long long" type.
> Is it possible that you are not aware that many embedded devices do not run
> on 64-bit processors, or that this type isn't even part of the latest C++ spec?

It seems you have no idea about compiler architectures. The 'long long'
type has nothing to do with the processor's word size. It is needed for
intermediate results of multiplications, for example, and is purely a
software issue. Please get a decent compiler!

BTW, the 64-bit version of PicoLisp uses 128-bit intermediate values
(directly supported by the processor's mul/div instructions of course).


> PicoLISP includes various other GNU-isms that prevent it from compiling on
> other compilers--even those that are compliant with the latest ANSI-C spec.

See above. The target is Linux, so GNU is no problem.


> Many experienced software developers with many years in the industry would
> consider it *unprofessional* to write C code that isn't portable to other
> compilers.  Just because you and your little net friends all use gcc and
> Linux doesn't mean everybody does.

Take a look at the 64-bit version. It doesn't use 'gcc', and even no
C-compiler at all ;-)


> Why make people to waste their time going through your code to fix these
> amateurish mistakes?

Then please keep your fingers off it.

Cheers,
- Alex

From mgryan@cruzio.com Tue Feb 15 11:55:55 2011
Return-path: <mgryan@cruzio.com>
Envelope-to: abu@localhost
Delivery-date: Tue, 15 Feb 2011 11:55:55 +0100
Received: from localhost
	([127.0.0.1] helo=software-lab ident=abu)
	by software-lab with esmtp (Exim 4.72)
	(envelope-from <mgryan@cruzio.com>)
	id 1PpIZX-0007ul-2P
	for abu@localhost; Tue, 15 Feb 2011 11:55:55 +0100
X-Envelope-From: <mgryan@cruzio.com>
X-Envelope-To: <abu@software-lab.de>
X-Delivery-Time: 1297767059
X-UID: 96670
X-RZG-CLASS-ID: mi
Received: from post.strato.de [81.169.145.136]
	by software-lab with POP3 (fetchmail-6.3.18)
	for <abu@localhost> (single-drop); Tue, 15 Feb 2011 11:55:55 +0100 (CET)
Received: from mail.cruzio.com ([63.249.93.182])
	by mailin.webmailer.de (plinge mi36) (RZmta 25.3)
	with ESMTP id A05f44n1FAQgmn for <abu@software-lab.de>;
	Tue, 15 Feb 2011 11:50:58 +0100 (MET)
Received: from avalon.cruzio.com (66-53-120-126.stkn.mdsg-pacwest.com [66.53.120.126])
	by mail.cruzio.com with SMTP id p1FAospY046230
	for <@mail.cruzio.com:abu@software-lab.de>; Tue, 15 Feb 2011 02:50:55 -0800 (PST)
Message-Id: <201102151050.p1FAospY046230@mail.cruzio.com>
Subject: Re: PicoLISP portability
To: abu@software-lab.de (Alexander Burger)
Received:  by avalon.cruzio.com; Tue, 15 Feb 11 02:36 PST
Date: Tue, 15 Feb 2011 02:36:42 -0800 (PST)
From: "Mark Ryan" <mgryan@cruzio.com>
In-Reply-To: <20110215074458.GA29615@software-lab.de> from "Alexander Burger" at Feb 15, 2011 08:44:58 AM
X-Mailer: ELM [version 2.5 PL6]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: RO
X-Status: A
Content-Length: 3624
Lines: 96

Thanks for the reply.  I enjoyed hearing the history of PicoLISP.
It's nice to know that it once ran on real UNIX before you crippled it.

Yes, why bother writing portable code when the GNU tools and Linux are
*perfect* for *every* purpose.   Why would anyone use anything else?
(That's the sort of "Linux uber alles!" answer I have come to expect.
It merely means the person has no idea what other operating systems do--
and probably thinks that all computers are PCs, Macs, or virtual
machines.)

Maybe you should hold off your statement about Linux's portability
until you have personally ported it to a new platform--especially
a non-Intel platform.  How the HAL layer?  :-)

You do not respond at all to the point that "Pico" LISP is not very
suitable for embedded use.  I guess that's because it's isn't the
first time you've heard that complaint.

If you know of an *efficient* implementation of 64-bit integer type on
a 32-bit register compiler, I'd love to hear about it (and so would
Donald Knuth).   At best, it's clunky.   Floating point (double or long
double) would be better, since ia32 and some embedded systems have
floating point instructions (or a co-processor).  Or you could rewrite
the order of calculations not to require such big intermediate numbers.
If you cared, that is.

Oh but I forget: your play book says "efficiency doesn't matter,
embedded sysetms don't matter, C compilers other than GNU don't matter,
operating systems other than Linux don't matter."  What really matters,
apparently, is you -- not other people -- certainly not developers.

Fortunately, there are many implementations of LISP to chose from.

Mark

From abu@software-lab.de Tue Feb 15 12:27:23 2011
Return-path: <abu@software-lab.de>
Envelope-to: abu@localhost
Delivery-date: Tue, 15 Feb 2011 12:27:23 +0100
Received: from localhost
	([127.0.0.1] helo=software-lab ident=abu)
	by software-lab with esmtp (Exim 4.72)
	(envelope-from <abu@software-lab.de>)
	id 1PpJ3z-0004if-Qi
	for abu@localhost; Tue, 15 Feb 2011 12:27:23 +0100
X-Envelope-From: <abu@software-lab.de>
X-Envelope-To: <abu@software-lab.de>
X-Delivery-Time: 1297769176
X-UID: 96676
X-Authentication-Results: mailin.webmailer.de (bertie mi50) (RZmta 25.3)
	header.From=software-lab.de;
	dkim=pass
X-RZG-CLASS-ID: mi
Received: from post.strato.de [81.169.145.136]
	by software-lab with POP3 (fetchmail-6.3.18)
	for <abu@localhost> (single-drop); Tue, 15 Feb 2011 12:27:23 +0100 (CET)
Received: from mo-p00-ob.rzone.de ([81.169.146.160])
	by mailin.webmailer.de (bertie mi50) (RZmta 25.3)
	with ESMTP id s0637cn1FBE65f for <abu@software-lab.de>;
	Tue, 15 Feb 2011 12:26:16 +0100 (MET)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1297769176; l=2334;
	s=domk; d=software-lab.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=sKUzl0+72uV+1eLjgCoutiVsNVA=;
	b=Qd2WX5DuWnHP7CmMD45bVtweUuqiK7v2CmQ2VZC/2FWo2eDsbe+2hy7XS878oBA5g1I
	LFQFmgx0mhQBOm04ihRFT15cqpU323SO1UjihSC4GZRtsdHNZU+ybBrurFZyx11cfU4+d
	5HEI7irE2T2iCb2zTz//VPCkiKGf9ZOz54g=
X-RZG-AUTH: :LW4RVVOnfesGyS0uS7OMacuCIvMeOzH1j5m4YTwauIPRpwlvJMbL6kUgW2vl99q4Eg==
X-RZG-CLASS-ID: mo00
Received: from software-lab (pd9568a7a.dip0.t-ipconnect.de [217.86.138.122])
	by post.strato.de (klopstock mo4) (RZmta 25.5)
	with ESMTPA id h05c1an1FADCdd ; Tue, 15 Feb 2011 12:26:16 +0100 (MET)
Received: from abu by software-lab with local (Exim 4.72)
	(envelope-from <abu@software-lab.de>)
	id 1PpJ2t-0004Wi-M4; Tue, 15 Feb 2011 12:26:15 +0100
Date: Tue, 15 Feb 2011 12:26:15 +0100
From: Alexander Burger <abu@software-lab.de>
To: Mark Ryan <mgryan@cruzio.com>
Subject: Re: PicoLISP portability
Message-ID: <20110215112615.GA3215@software-lab.de>
References: <20110215074458.GA29615@software-lab.de>
 <201102151050.p1FAospY046230@mail.cruzio.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <201102151050.p1FAospY046230@mail.cruzio.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Status: RO
Content-Length: 2275
Lines: 69

Hi Mark,

what's your problem?

> Thanks for the reply.  I enjoyed hearing the history of PicoLISP.
> It's nice to know that it once ran on real UNIX before you crippled it.

SCO, 20 years ago? Come on!


> Yes, why bother writing portable code when the GNU tools and Linux are
> *perfect* for *every* purpose.   Why would anyone use anything else?

I didn't say "perfect". Just pragmatic.

Why don't you just accept that there were reasons to target it for a
single architecture? Simplicity!

If you don't like it, YOU are free to change it.


> It merely means the person has no idea what other operating systems do--
> and probably thinks that all computers are PCs, Macs, or virtual
> machines.)

Don't talk about things you don't know. I've wire-wrapped computers on
the TTL level in the past, and wrote my own operating systems on them.


> You do not respond at all to the point that "Pico" LISP is not very
> suitable for embedded use.  I guess that's because it's isn't the
> first time you've heard that complaint.

No. You are in fact the first who complains.

PicoLisp has been used in embedded systems since many years, under
ucLinux and recently OpenWRT.


> If you know of an *efficient* implementation of 64-bit integer type on
> a 32-bit register compiler, I'd love to hear about it (and so would

You still didn't get the point. There is no intensive processing done in
PicoLisp with the double-length data type. You should switch on your
brain and take a look before you ramble. That's less embarrassing.

I told you: These are _intermediate_ results, to avoid loss of precision
for multiplications immediately followed by divisions. Any decent CPU
has a double-precision multiplication result after a (machine-level)
'mul' instruction. If your compiler doesn't take advantage of it, it is
not my fault.

Other usages include values which simply don't fit into 32 bits, as the
number of microseconds, or the IDs of database symbols.


> floating point instructions (or a co-processor).  Or you could rewrite
> the order of calculations not to require such big intermediate numbers.
> If you cared, that is.

Again: YOU are free to do it.


> Fortunately, there are many implementations of LISP to chose from.

Indeed! Please do so!

Sincerely,
- Alex

From mgryan@cruzio.com Tue Feb 15 14:37:54 2011
Return-path: <mgryan@cruzio.com>
Envelope-to: abu@localhost
Delivery-date: Tue, 15 Feb 2011 14:37:54 +0100
Received: from localhost
	([127.0.0.1] helo=software-lab ident=abu)
	by software-lab with esmtp (Exim 4.72)
	(envelope-from <mgryan@cruzio.com>)
	id 1PpL6A-0001Vb-3E
	for abu@localhost; Tue, 15 Feb 2011 14:37:46 +0100
X-Envelope-From: <mgryan@cruzio.com>
X-Envelope-To: <abu@software-lab.de>
X-Delivery-Time: 1297776975
X-UID: 96688
X-RZG-CLASS-ID: mi
Received: from post.strato.de [81.169.145.136]
	by software-lab with POP3 (fetchmail-6.3.18)
	for <abu@localhost> (single-drop); Tue, 15 Feb 2011 14:37:46 +0100 (CET)
Received: from mail.cruzio.com ([63.249.93.182])
	by mailin.webmailer.de (ahmed mi51) (RZmta 25.3)
	with ESMTP id 104a25n1FDKUc4 for <abu@software-lab.de>;
	Tue, 15 Feb 2011 14:36:15 +0100 (MET)
Received: from avalon.cruzio.com (67-150-143-106.stkn.mdsg-pacwest.com [67.150.143.106])
	by mail.cruzio.com with SMTP id p1FDa9Q2074053
	for <@mail.cruzio.com:abu@software-lab.de>; Tue, 15 Feb 2011 05:36:10 -0800 (PST)
Message-Id: <201102151336.p1FDa9Q2074053@mail.cruzio.com>
Subject: Re: PicoLISP portability
To: abu@software-lab.de (Alexander Burger)
Received:  by avalon.cruzio.com; Tue, 15 Feb 11 05:41 PST
Date: Tue, 15 Feb 2011 05:41:16 -0800 (PST)
From: "Mark Ryan" <mgryan@cruzio.com>
In-Reply-To: <20110215112615.GA3215@software-lab.de> from "Alexander Burger" at Feb 15, 2011 12:26:15 PM
X-Mailer: ELM [version 2.5 PL6]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: RO
X-Status: A
Content-Length: 6056
Lines: 149

Hi Alex,

To wrap this up, let me try to give non-inflamatory reponses to the
points you raised.

> Hi Mark,
>
> what's your problem?
>
> > Thanks for the reply.  I enjoyed hearing the history of PicoLISP.
> > It's nice to know that it once ran on real UNIX before you crippled it.
>
> SCO, 20 years ago? Come on!

Actually, supporting UNIX meant a lot more than just SCO.  If PicoLISP
ran on SCO UNIX (SVR3.2-based), then it would probably build and run on
a huge number of SVR3.2 and SVR4-based UNIXes.  It might even have been
an easy port to Sun Solaris, which is still being shipped.

In any case, at that point, PicoLISP would have been extremely portable.

> > Yes, why bother writing portable code when the GNU tools and Linux are
> > *perfect* for *every* purpose.   Why would anyone use anything else?
>
> I didn't say "perfect". Just pragmatic.

Only if the target machine has a PC-like architecture.  That covers
maybe 10% of the computers in use today.

And only if the machine's mission resembles a PC's.  If you need say,
fault tolerance, or an A-level trusted system,  or software interfaces
that don't change all the time, or device driver support from hardware
manufacturers, then you'll have to use a different OS, because Linux
won't do the job.

(BTW, I'm writing this on an Orange Book B-level security UNIX system.)

> Why don't you just accept that there were reasons to target it for a
> single architecture? Simplicity!

It's also simpler to drive down the center of the road.  I can accept
that, I just think it's stupid.

Why shouldn't an interpreter be portable?  It has no hardware dependencies--
unless the programmer introduces them through carelessness or indifference.

> If you don't like it, YOU are free to change it.

"Hey, I'm not rsponsible for this code, I just maintain it...."
That's like a chef saying--after you've sat down to dinner--"if you
don't like the food, YOU are free to change it."   It's an abdication of
responsibility.

It's easier for me to just to find some better code.

> > It merely means the person has no idea what other operating systems do--
> > and probably thinks that all computers are PCs, Macs, or virtual
> > machines.)
>
> Don't talk about things you don't know. I've wire-wrapped computers on
> the TTL level in the past, and wrote my own operating systems on them.

Ah--a toy OS. I'm talking about porting a modern, grown-up OS: hundreds
of thousands of lines of code.  You haven't done that or you wouldn't make
such blythe statements about how easily portable Linux is.   No mature OS
is easy to port--though some are easier than others.

UNIX has been ported to the most platforms of any OS in history, but it
was NOT a simple matter to port it, at least, not after it became capable
and complex (e.g., SMP support, NUMA support, etc).  Take it from me.
Even with the "platform support module" interface that USL added to try
make it easier to port SVR4.2 to PC-like systems, it was not easy.
You had to write all the routines to bring up a CPU on the fly, take down
a CPU on the fly, handled the cross-processor interrupt, etc.  There
are dozens of kernel-level spin locks to worry about.  Fun, but not easy.

On a toy OS, when you get it to boot you are essentially done.   On a
real OS,  like UNIX or Linux, the work has only started.  You got to get
it to run efficiently and reliably with different numbers of CPUs,
different amounts of memory, different of concurrent users, different
network load levels, and even different I/O hardware devices and device
drivers.

It took YEARS for Linux just to start fully supporting the Intel PC
architecture.  The early releases didn't even prioritize interrupts (!).
"Ladies and Gentlemen, for his next trick, Mr. Torvalds will re-invent
the wheel!"  Someday he may even get around to inventing the pneumatic
tire.

> > You do not respond at all to the point that "Pico" LISP is not very
> > suitable for embedded use.  I guess that's because it's isn't the
> > first time you've heard that complaint.
>
> No. You are in fact the first who complains.
>
> PicoLisp has been used in embedded systems since many years, under
> ucLinux and recently OpenWRT.

That must have been before you crippled it and stuck in the huge numbers.

>
> > If you know of an *efficient* implementation of 64-bit integer type on
> > a 32-bit register compiler, I'd love to hear about it (and so would
>
> You still didn't get the point. There is no intensive processing done in
> PicoLisp with the double-length data type. You should switch on your
> brain and take a look before you ramble. That's less embarrassing.

No, you don't get the point: compilers for embedded 16-bit and 32-bit CPUs
don't support 128-bit numbers.  It' insane to suggest that they should.
But they might very well want to run LISP.

PicoLISP shouldn't be about gcc or Linux,  or about Linux-head politics
and hatred for SCO, it should be about *LISP*.

> I told you: These are _intermediate_ results, to avoid loss of precision
> for multiplications immediately followed by divisions. Any decent CPU
> has a double-precision multiplication result after a (machine-level)
> 'mul' instruction. If your compiler doesn't take advantage of it, it is
> not my fault.

You are assuming every computer has a 64-bit processor.
So tell me...where are you gonna put the chiptop fan in a
digital camara?

> Other usages include values which simply don't fit into 32 bits, as the
> number of microseconds, or the IDs of database symbols.

Sounds like a design flaw.  Interpreters -- and LISP interpreters
in particular -- existed long before 128-bit C types did.

>
> > floating point instructions (or a co-processor).  Or you could rewrite
> > the order of calculations not to require such big intermediate numbers.
> > If you cared, that is.
>
> Again: YOU are free to do it.
>
>
> > Fortunately, there are many implementations of LISP to chose from.
>
> Indeed! Please do so!
>
> Sincerely,
> - Alex

Better luck next time,

Mark

From abu@software-lab.de Tue Feb 15 15:40:27 2011
Return-path: <abu@software-lab.de>
Envelope-to: abu@localhost
Delivery-date: Tue, 15 Feb 2011 15:40:27 +0100
Received: from localhost
	([127.0.0.1] helo=software-lab ident=abu)
	by software-lab with esmtp (Exim 4.72)
	(envelope-from <abu@software-lab.de>)
	id 1PpM4p-0004CY-2x
	for abu@localhost; Tue, 15 Feb 2011 15:40:27 +0100
X-Envelope-From: <abu@software-lab.de>
X-Envelope-To: <abu@software-lab.de>
X-Delivery-Time: 1297780779
X-UID: 96694
X-Authentication-Results: mailin.webmailer.de (blert mi18) (RZmta 25.3)
	header.From=software-lab.de;
	dkim=pass
X-RZG-CLASS-ID: mi
Received: from post.strato.de [81.169.145.136]
	by software-lab with POP3 (fetchmail-6.3.18)
	for <abu@localhost> (single-drop); Tue, 15 Feb 2011 15:40:27 +0100 (CET)
Received: from mo-p00-ob.rzone.de ([81.169.146.161])
	by mailin.webmailer.de (blert mi18) (RZmta 25.3)
	with ESMTP id I03534n1FEOUrc for <abu@software-lab.de>;
	Tue, 15 Feb 2011 15:39:39 +0100 (MET)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1297780779; l=3915;
	s=domk; d=software-lab.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=DHjcDeCykHoAAP0NzaL9uyBCTvc=;
	b=FNGtBNBWKVcPR/2krYcdYtuRBHiTDE7ja+57m3/aPimdra/A6hzq8X3eQTX8Vc6KIYa
	gl6srRFNNGpoakd9UO+FHNgJigzev6s2cg+Q4zR+IcQ6AZkdwhLjgIxQ8jrD2jNh71SFs
	Vx1WaYOexObi0twy21KTBMe3tUnOTC6BXQw=
X-RZG-AUTH: :LW4RVVOnfesGyS0uS7OMacuCIvMeOzH1j5m4YTwauIPRpwlvJMbL6kUgW2vl99q4Eg==
X-RZG-CLASS-ID: mo00
Received: from software-lab (pd9568a7a.dip0.t-ipconnect.de [217.86.138.122])
	by post.strato.de (mrclete mo19) (RZmta 25.5)
	with ESMTPA id C06c4dn1FEW0pQ ; Tue, 15 Feb 2011 15:39:37 +0100 (MET)
Received: from abu by software-lab with local (Exim 4.72)
	(envelope-from <abu@software-lab.de>)
	id 1PpM41-00043F-O2; Tue, 15 Feb 2011 15:39:37 +0100
Date: Tue, 15 Feb 2011 15:39:37 +0100
From: Alexander Burger <abu@software-lab.de>
To: Mark Ryan <mgryan@cruzio.com>
Subject: Re: PicoLISP portability
Message-ID: <20110215143937.GA16369@software-lab.de>
References: <20110215112615.GA3215@software-lab.de>
 <201102151336.p1FDa9Q2074053@mail.cruzio.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <201102151336.p1FDa9Q2074053@mail.cruzio.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Status: RO
Content-Length: 3838
Lines: 102

Hi Mark,

> To wrap this up, let me try to give non-inflamatory reponses to the
> points you raised.

No problem. I enjoyed our discussion :)


> Actually, supporting UNIX meant a lot more than just SCO.  If PicoLISP
> ran on SCO UNIX (SVR3.2-based), then it would probably build and run on
> a huge number of SVR3.2 and SVR4-based UNIXes.  It might even have been
> an easy port to Sun Solaris, which is still being shipped.

And also _is_ no problem, afaik.

I used it for 5 years in a project under FreeBSD. Other people provided
Makefile modifications for OpenBSD, Mac OS X (Darwin), NetBSD and
Cygwin. I recomend you take a look into the Makefile.

Currently I'm in contact with a person in Russia who ports the 64-bit
version go SunOS (Solaris, SunStudio).

I myself don't have the resources (and also not the time) to do such
ports.


> > If you don't like it, YOU are free to change it.
>
> "Hey, I'm not rsponsible for this code, I just maintain it...."
> That's like a chef saying--after you've sat down to dinner--"if you
> don't like the food, YOU are free to change it."   It's an abdication of
> responsibility.

Now hold on! I'm free to write PicoLisp the way I am convinced of. YOU
cannot demand ANYTHING. Or are you willing to PAY for it?

I wrote PicoLisp for my own company, to increase our own productivity.
For practical purposes, and applications we need for our customers.
Database servers for web applications. That's what it is targeted and
optimized for.

I released it into the public for anybody who wants to use it. But if
you have additional requirements, it is your problem.


> such blythe statements about how easily portable Linux is.   No mature OS
> is easy to port--though some are easier than others.

Please read what I wrote. I never said it is easy. But you can't deny
that Linux is ported to more architectures than any other OS.


> > PicoLisp has been used in embedded systems since many years, under
> > ucLinux and recently OpenWRT.
>
> That must have been before you crippled it and stuck in the huge numbers.

No. These "huge" numbers (!) were there all the time.


> > > If you know of an *efficient* implementation of 64-bit integer type on
> > > a 32-bit register compiler, I'd love to hear about it (and so would
> >
> > You still didn't get the point. There is no intensive processing done in
> > PicoLisp with the double-length data type. You should switch on your
> > brain and take a look before you ramble. That's less embarrassing.
>
> No, you don't get the point: compilers for embedded 16-bit and 32-bit CPUs
> don't support 128-bit numbers.  It' insane to suggest that they should.

I didn't say that. I said that each processor has a double-width
multiplication result. That was 16 bits on the 6809 which had a 8-bit
multiplication, 32 bits on the 8086 for its 16-bit multiplication, and
so on.

So, yes, PicoLisp uses an 128-bit result on x86-64.


> PicoLISP shouldn't be about gcc or Linux,  or about Linux-head politics
> and hatred for SCO, it should be about *LISP*.

Right. But somebody must do it. Either you do it, or we make a contract,
you pay me 80 EUR per hour, and I do it.


> > I told you: These are _intermediate_ results, to avoid loss of precision
> > for multiplications immediately followed by divisions. Any decent CPU
> > has a double-precision multiplication result after a (machine-level)
> > 'mul' instruction. If your compiler doesn't take advantage of it, it is
> > not my fault.
>
> You are assuming every computer has a 64-bit processor.

Sigh.

Before PicoLisp, I wrote a Lisp on the Z80 (you probably don't know that
processor, if I consider what you said so far: It is an 8-bit CPU,
probably the most often built processor in history). Even that Lisp used
numbers with up to 127 bytes (yes, that's 1016 bits).

Cheers,
- Alex