Re: picoLisp on FreeBSD 9.1 x64

2013-01-08 Thread Alexander Burger
Hi Mansur,

 Seems all right with native.l:
 # ./pil misc/fibo.l +
 : (cFibo 36)
 - 14930352

Very good! Then we don't have to change anything :)

♪♫ Alex
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


Re: picoLisp on FreeBSD 9.1 x64

2013-01-07 Thread Alexander Burger
Hi Mansur,

 I've found the solution :)
 One should use -rdynamic for LD_MAIN too.
 ...
 So, now all tests passed with OK.

Great!


 Alex, I will send you my files soon.

Many thanks! I've received them, and made a new release with your
changes. Everybody having FreeBSD is invited for testing!


 As I understand, it's not possible to send them as attachment to mailing list

Strange. Attachments to the mailing list used to work in other cases ...

♪♫ Alex
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


Re: picoLisp on FreeBSD 9.1 x64

2013-01-07 Thread Mansur Mamkin
Hi Alex, 
new testing release works fine, thanks!

Notes for FreeBSD x86-64 users:
For building 64bit version you will need working picolisp interpreter (e.g. 
32bit one or java version) or asm-files, 
you can get them here:
http://dl.dropbox.com/u/54259642/picoLisp/picoLisp-FreeBSD-x86-64.tgz
As I know, /usr/include/ is not 32bit-aware on 64bit FreeBSD installation, so 
for building of 32bit interpreter on these systems you will need 32-bit jail or 
include-directory tree from 32bit system.
So easiest way I see for those who has not java installed is extracting 
asm-files from picoLisp-FreeBSD-x86-64.tgz into src64/ and doing:
cd src64  gmake

Best regards,
Mansur

 Hi Mansur,
 
  I've found the solution :)
  One should use -rdynamic for LD_MAIN too.
  ...
  So, now all tests passed with OK.
 
 Great!
 
 
  Alex, I will send you my files soon.
 
 Many thanks! I've received them, and made a new release with your
 changes. Everybody having FreeBSD is invited for testing!
 
 
  As I understand, it's not possible to send them as attachment to mailing 
  list
 
 Strange. Attachments to the mailing list used to work in other cases ...
 
 ♪♫ Alex
 -- 
 UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
 PԔ � j)mX�����zV�u�.n7�

Re: picoLisp on FreeBSD 9.1 x64

2013-01-07 Thread Alexander Burger
Hi Mansur,

 new testing release works fine, thanks!

One more point: How about lib/native.l?

I suspect it needs to be changed too. You could test it with e.g.

   $ ./pil misc/fibo.l +
   : (cFibo 36)
   - 14930352

♪♫ Alex
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


Re: picoLisp on FreeBSD 9.1 x64

2013-01-06 Thread Mansur Mamkin
Hi!
That's my inattention.
I've found the solution :)
One should use -rdynamic for LD_MAIN too.
Without this e.g. dlopen(lib/ht) fails with Undefined symbol 'Nil' error
So, now all tests passed with OK.
Alex, I will send you my files soon. As I understand, it's not possible to send 
them as attachment to mailing list
Best regards, 
Mansur

Суббота,  5 января 2013, 18:06 +01:00 от Alexander Burger 
a...@software-lab.de:
 Hi Mansur,
 
  I tried different options, also without stripping, but with no success.
  Perhaps someone can help to write small assembly program with shared
  library for test dlopen/dlsym calls?
 
 What did you use for the 'LD-SHARED' linker options? The Makefile of
 'pil32' uses -shared -export-dynamic for FreeBSD (in addition to
 -m32 which obviously doesn't make sense here). Perhaps this works
 for 64-bits too?
 
 
 An assembly program is probably not so helpful. Does FreeBSD have
 the 'ltrace' utility? If so, you could do
 
$ ltrace bin/picolisp 2xxx
: (ht:Prin 123)
 
 and then look into 'xxx' for something like
 
dlopen(lib/ht, 257)= 0x011700f0
dlsym(0x011700f0, Prin)= 0x7fe3f3f9f222
 
 
 I use 'gdb' in such cases to single-step through the program, but that's
 not what I would really recommend ;-)
 
 ♪♫ Alex
 -- 
 UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
 

Re: picoLisp on FreeBSD 9.1 x64

2013-01-05 Thread Alexander Burger
Hi Mansur,

 I tried different options, also without stripping, but with no success.
 Perhaps someone can help to write small assembly program with shared
 library for test dlopen/dlsym calls?

What did you use for the 'LD-SHARED' linker options? The Makefile of
'pil32' uses -shared -export-dynamic for FreeBSD (in addition to
-m32 which obviously doesn't make sense here). Perhaps this works
for 64-bits too?


An assembly program is probably not so helpful. Does FreeBSD have
the 'ltrace' utility? If so, you could do

   $ ltrace bin/picolisp 2xxx
   : (ht:Prin 123)

and then look into 'xxx' for something like

   dlopen(lib/ht, 257)= 0x011700f0
   dlsym(0x011700f0, Prin)= 0x7fe3f3f9f222


I use 'gdb' in such cases to single-step through the program, but that's
not what I would really recommend ;-)

♪♫ Alex
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


Re: picoLisp on FreeBSD 9.1 x64

2013-01-04 Thread Alexander Burger
Hi Mansur,

 I've got working pil x64 on BSD. All tests are passed,

Great! Congratulations :)


 but with ext and ht:
 [test/src/ext.l:5] !? (ext:Snx PicoLisp is not Common Lisp)
 ext:Snx -- Undefined
 ...
 [test/src/ht.l:5] !? (ht:Prin 123äöüiÄÖÜß)
 ht:Prin -- Undefined

I suspect that this is a problem of the 'LD-SHARED' value in
src64/Makefile. The libraries lib/ext and lib/ht may be created
wrongly, so that they are either not recognized by dlopen(), or the
symbols are not found by dlsym().

♪♫ Alex
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


Re: picoLisp on FreeBSD 9.1 x64

2013-01-04 Thread Jorge Acereda
On Fri, Jan 4, 2013 at 12:56 PM, Alexander Burger a...@software-lab.de wrote:
 Hi Mansur,

 I've got working pil x64 on BSD. All tests are passed,

 Great! Congratulations :)


 but with ext and ht:
 [test/src/ext.l:5] !? (ext:Snx PicoLisp is not Common Lisp)
 ext:Snx -- Undefined
 ...
 [test/src/ht.l:5] !? (ht:Prin 123äöüiÄÖÜß)
 ht:Prin -- Undefined

 I suspect that this is a problem of the 'LD-SHARED' value in
 src64/Makefile. The libraries lib/ext and lib/ht may be created
 wrongly, so that they are either not recognized by dlopen(), or the
 symbols are not found by dlsym().

Perhaps it's the same problem I experienced under Darwin. Try changing
the 'STRIP=strip' line to 'STRIP=echo' and see if that fixes the
problem. Then it should just be a matter of finding the right strip
flags for your platform.




 ♪♫ Alex
 --
 UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


Re: picoLisp on FreeBSD 9.1 x64

2013-01-04 Thread Mansur Mamkin
--e1eimUmj-ZHXgwhzIGfT8Jy1h:1357366514
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64

SGkgYWxsLApJIHRyaWVkIGRpZmZlcmVudCBvcHRpb25zLCBhbHNvIHdpdGhvdXQgc3RyaXBwaW5n
LCBidXQgd2l0aCBubyBzdWNjZXNzLgpQZXJoYXBzIHNvbWVvbmUgY2FuIGhlbHAgdG8gd3JpdGUg
c21hbGwgdGVzdCBhc3NlbWJseSBwcm9ncmFtIHdpdGggc2hhcmVkIGxpYnJhcnkgYW5kIGRsb3Bl
bi9kbHN5bSBjYWxscz8KSSBhbSBhbHNvIGdvaW5nIHRvIHRyeSA6KQpCdHcgSSd2ZSBhdHRhY2hl
ZCBmaWxlcywgd2hpY2ggSSBmb3Jnb3QgdG8gYWRkIGluIG9uZSBvZiB0aGUgcHJldmlvdXMgbGV0
dGVycwoKQmVzdCByZWdhcmRzLCAKTWFuc3VyIAoKCtCf0Y/RgtC90LjRhtCwLCAgNCDRj9C90LLQ
sNGA0Y8gMjAxMywgMTQ6MzUgKzAxOjAwINC+0YIgSm9yZ2UgQWNlcmVkYSA8amFjZXJlZGFAZ21h
aWwuY29tPjoKPiBPbiBGcmksIEphbiA0LCAyMDEzIGF0IDEyOjU2IFBNLCBBbGV4YW5kZXIgQnVy
Z2VyIDxhYnVAc29mdHdhcmUtbGFiLmRlPiB3cm90ZToKPiA+IEhpIE1hbnN1ciwKPiA+Cj4gPj4g
SSd2ZSBnb3Qgd29ya2luZyBwaWwgeDY0IG9uIEJTRC4gQWxsIHRlc3RzIGFyZSBwYXNzZWQsCj4g
Pgo+ID4gR3JlYXQhIENvbmdyYXR1bGF0aW9ucyA6KQo+ID4KPiA+Cj4gPj4gYnV0IHdpdGggImV4
dCIgYW5kICJodCI6Cj4gPj4gW3Rlc3Qvc3JjL2V4dC5sOjVdICE/IChleHQ6U254ICJQaWNvTGlz
cCBpcyBub3QgQ29tbW9uIExpc3AiKQo+ID4+IGV4dDpTbnggLS0gVW5kZWZpbmVkCj4gPj4gLi4u
Cj4gPj4gW3Rlc3Qvc3JjL2h0Lmw6NV0gIT8gKGh0OlByaW4gIjE8Mj4zJsOkw7bDvDxpPsOEw5bD
nMOfIikKPiA+PiBodDpQcmluIC0tIFVuZGVmaW5lZAo+ID4KPiA+IEkgc3VzcGVjdCB0aGF0IHRo
aXMgaXMgYSBwcm9ibGVtIG9mIHRoZSAnTEQtU0hBUkVEJyB2YWx1ZSBpbgo+ID4gInNyYzY0L01h
a2VmaWxlIi4gVGhlIGxpYnJhcmllcyAibGliL2V4dCIgYW5kICJsaWIvaHQiIG1heSBiZSBjcmVh
dGVkCj4gPiB3cm9uZ2x5LCBzbyB0aGF0IHRoZXkgYXJlIGVpdGhlciBub3QgcmVjb2duaXplZCBi
eSBkbG9wZW4oKSwgb3IgdGhlCj4gPiBzeW1ib2xzIGFyZSBub3QgZm91bmQgYnkgZGxzeW0oKS4K
PiAKPiBQZXJoYXBzIGl0J3MgdGhlIHNhbWUgcHJvYmxlbSBJIGV4cGVyaWVuY2VkIHVuZGVyIERh
cndpbi4gVHJ5IGNoYW5naW5nCj4gdGhlICdTVFJJUD1zdHJpcCcgbGluZSB0byAnU1RSSVA9ZWNo
bycgYW5kIHNlZSBpZiB0aGF0IGZpeGVzIHRoZQo+IHByb2JsZW0uIFRoZW4gaXQgc2hvdWxkIGp1
c3QgYmUgYSBtYXR0ZXIgb2YgZmluZGluZyB0aGUgcmlnaHQgc3RyaXAKPiBmbGFncyBmb3IgeW91
ciBwbGF0Zm9ybS4KPiAKPiAKPiAKPiA+Cj4gPiDimarimasgQWxleAo+ID4gLS0KPiA+IFVOU1VC
U0NSSUJFOiBtYWlsdG86cGljb2xpc3BAc29mdHdhcmUtbGFiLmRlP3N1YmplY3Q9VW5zdWJzY3Jp
YmUKPiAtLQo+IFVOU1VCU0NSSUJFOiBtYWlsdG86cGljb2xpc3BAc29mdHdhcmUtbGFiLmRlP3N1
YmplY3Q9VW5zdWJzY3JpYmUKPiA=

--e1eimUmj-ZHXgwhzIGfT8Jy1h:1357366514
Content-Type: application/octet-stream; name==?UTF-8?B?YnNkLWZpbGVzLnRneg==?=
Content-Disposition: attachment
Content-Transfer-Encoding: base64

H4sIAO9h5lAAA+1YbXObRhDu1+pXbO02lWJLPl6EHbfxGAOSmSJQAVl2v1AicMJEFirg2En/fPcQ
HCelTWfcSTvpsKOJtM/u7e3b7Z3zKo8kcbAOi8Wbrz4XEUIUWQb6jbT7TchQGIIgkmNBVogsSkAE
SRCkr4B8No84us+LMENXsjQtPqX38CaOl5+Q7wb3hVC/34d1skitJF8P0ix5fZRni6NVXAwWX4tE
EPoC6YsEBOmUDPEzqGtG4IAohHQODg7Y+u2lYh8/kgDkxSkRTyXlo6Xn59BXDhU4UA5P4Py8Ax3Y
T1aL5X0Uw49oJno1eHPGY2G2Do8SugHiB1u6FEXRjiB/nx/l6eLtZgXax1oXyQLepUkEydrIsm64
eg/x4yEs3oQZPM978HsHkGIUUdieWdYh7JlT+C6nYJqd4q+9Q8jxU2Ql0sV/V2mv90Pnvy7mE+jx
ROkr8uA2i+OLPBos0igefKrNn0LN+ReOh4T/LkkkQ2lz/iVJlIb0/IvDY/Ivn/9/aucLPf/7ILy4
C98LpLMPH9JVsniL5yl5my7D5PxD+mqFZyq7P0Nhd9EDL70tHsIsBit8NQB1GT+GqyjO4OI+ex1n
HdTy3udFfAd34SJL806XthN8X56PQAXSo2drES6XEATl0QHYh3FcQBhFWZznkN5W2t9TzWUEKnTV
HtWy0jCCd+HyPqaSLC46W9a1pxinpjWq5RUpBrWKH3Z22I/iW5wsZ8Hc81V/5nUfez/iwDzrBvPA
tH1k4Rl26/Fxb0vVmU4NnSqiKpXiz7MN2z87eg61NUhuYZ2lC+pbkuM4SdfrOILnR8zY3BxV1sqd
6b7MEXj5Ethmva0l5thWrc2a7SXfcEvg2TPYkRHOjG+4EzTERcxUeyz1D8lt5bUXjHA5zWXjc1NC
D8xeXQ06gu9zKsPegQv4tZsuCtijedrblPBuvQvTtd1ud7OU5ZxmYJP8nY6gbiWvV+Fy168qMU9w
rPLgIxe+qVyg2fxz6V/FRGFsgFXZbUyFUC5eRR+FVMTZHQbllceojKeq0JOD2XGW6n54LJreh3fJ
aVycFvlL6TR/eCl9ibdbS39HO/c/Hv/8M97/f/r+l0WiVPe/KBBZwX6U5eNh+/7/N2gfjFWUhCu8
hDr7Fp76eZpFefIh7uwrMp0C5Y3Z6ca/3YNhO4btg9irWLwCXZBr7kLVR/Ci5tSxatogDRmvaYaH
f0bU/NScGiAxU5pj267hGT4M0SBum67j1dHtYlUsNxpO4OqObd3QgVoBc7cEhF6jMXeZd06guYaK
9oQGMa41C0QinzDEd2e2BgIRZQapeHfZOtQ6o2Bs+COdbTMKvJKvrY70QLMc49rQqAp6nhdRUiXs
YoZ3zi+8eRp2gDDn1kS9nqr+pWXYLDZqYgWw920QlD/Xe40gvS9qAf7kJVipWoI/qYS6Ey0xixsd
17f0wFJ/aXJWImPLuVAxL0Ol9J9L+shytJ+aKlmBf4NVEwnj55eGrSHSaOArwfWh0aBhnTBuamIi
lYr1DOMnmkymXQLazOVy7eoWetDwc5fyEuNnNuXFrVpZnNwreZmXW2hvq5gUELeBedOpJeLMbVBY
h9iOfVFmhmsa7wb7SJGrDgiLKiJ8M9HRVgfoBxNHN1hCkMf+MOBY5BR8c2KAzJYE5mjig4IjkYd0
E7OkSCebDYvkLs43Qn/iNRlGJpiV9giHeJsdNivxWZGk9Vp8UZiOB3Idl4Y7WeqYrdYCq+RZurRA
05rtTHyOoKyO7mqCE4AJr8pdhePaEc1TdZfOiOrUlA+2KkBzrGq+6dhN6yGEZQh8rnvU4FK1dctw
m/5Rg4nqcdVEgPrrNQk3x4GODUE4Hh+FrMEoP6uKy219OZvyKiY3BJGdea4AEtkCRJC4BeWwYx1F
w7PcCQhyA9DUgzBsAO3S0puTRgEHdxVecPnAV3aTT2rD8xHgQvV9TK8o8IAzaw4rjcQBkXMLX8de
mXMsyEOYVE08tx3M9JhlYD7Dua9qRjkDaeniZbwo2DSkJ7psgqox68ZDgcb1YUC7Q27YSwcP/gkn
1tWbppIUcGy+s4MbQ3XLDNEhl2QbXA9sdVIeMPrHaPlfP1Vze1hTbH28EyZNLSmmj12E6o1UOlO8
KecqIqZt+AqwxvYcnHO4FANVhkN2x3l4Axkzz1B1vbkWzenUdXwnMKdXCsgCQ6+U4Eop7y+xLmG5
S0BXo5t0bsp1tLaJjX196Xg+vUuGDUqDdY2fdbYddYtaQJd5h5ELRurE5K7LEps6Lt/K9mZ7VgbK
mPbIAXZjqmZtR24Quml5M3BadCmNgVWswpojjYBtXPvlqPuvX0EttdRSSy211FJLLbXUUksttdRS
S/9f+gNmm3yjACgAAA==

--e1eimUmj-ZHXgwhzIGfT8Jy1h:1357366514--
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


Re: picoLisp on FreeBSD 9.1 x64

2013-01-04 Thread Mansur Mamkin
Hi all,
I tried different options, also without stripping, but with no success.
Perhaps someone can help to write small assembly program with shared library 
for test dlopen/dlsym calls?

Best regards, 
Mansur 

 Hi Mansur,
 
  I've got working pil x64 on BSD. All tests are passed,
 
 Great! Congratulations :)
 
 
  but with ext and ht:
  [test/src/ext.l:5] !? (ext:Snx PicoLisp is not Common Lisp)
  ext:Snx -- Undefined
  ...
  [test/src/ht.l:5] !? (ht:Prin 123äöüiÄÖÜß)
  ht:Prin -- Undefined
 
 I suspect that this is a problem of the 'LD-SHARED' value in
 src64/Makefile. The libraries lib/ext and lib/ht may be created
 wrongly, so that they are either not recognized by dlopen(), or the
 symbols are not found by dlsym().
 
 ♪♫ Alex
PԔ � j)mX�����zV�u�.n7�

Re: picoLisp on FreeBSD 9.1 x64

2013-01-03 Thread Mansur Mamkin
Hi Alex,
I've got working pil x64 on BSD. All tests are passed, but with ext and ht:
[test/src/ext.l:5] !? (ext:Snx PicoLisp is not Common Lisp)
ext:Snx -- Undefined
? 
...
The same with ht:
[test/src/ht.l:5] !? (ht:Prin 123äöüiÄÖÜß)
ht:Prin -- Undefined

# ls -l src64/x86-64*
-rw-r--r--  1 root  wheel  425208 Jan  3 22:42 src64/x86-64.freeBsd.base.o
-rw-r--r--  1 root  wheel  842406 Jan  3 22:42 src64/x86-64.freeBsd.base.s
-rw-r--r--  1 root  wheel3704 Jan  3 22:42 src64/x86-64.freeBsd.ext.o
-rw-r--r--  1 root  wheel5991 Jan  3 22:42 src64/x86-64.freeBsd.ext.s
-rw-r--r--  1 root  wheel   14712 Jan  3 22:42 src64/x86-64.freeBsd.ht.o
-rw-r--r--  1 root  wheel   17878 Jan  3 22:42 src64/x86-64.freeBsd.ht.s

# ls -l lib/ht lib/ext
-rwxr-xr-x  1 root  wheel   6864 Jan  3 22:42 lib/ext
-rwxr-xr-x  1 root  wheel  13984 Jan  3 22:42 lib/ht

I've attached archive with .code and .def files for bsd

Best regards,
Mansur


Re: picoLisp on FreeBSD 9.1 x64

2013-01-01 Thread Alexander Burger
Hi Mansur,

 Happy New year to all!

A happy New Year to you, and to all readers! :)


 but I get runtime errors:
 [/root/.pil/history:1] File lock: Invalid argument

This must be the fcntl() call in lockFile() (in src/io.c). It gets
passed the constant arguments F_SETLKW and F_RDLCK. What might be goes
wrong here?


 # ./pil app/main.l -main -go
 DB write: Invalid argument
 ...
 -rw-r--r--  1 root  wheel  2885162388670120960 Jan  1 11:57 1 --- 
 Look at file size:

It seems that the runtime system can't handle 64-bit file offsets.

When a PicoLisp database is created, the first two blocks are written.
In case of the demo application, the first DB file has a block size (see
app/er.l) of 512 bytes:

   (3 +Role +User +Sal) # 512 Prevalent objects

Thus, two blocks have a size of 1024 bytes, which is 0x400 in hex. If we
look at the above file size

   : (hex 2885162388670120960)
   - 280A27E80400

we see that the upper 32 bits of the size contain garbage. This
indicates that either 'off_t' isn't 64-bits wide, or the library can't
handle 64-bit file offsets.

♪♫ Alex
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


Re: picoLisp on FreeBSD 9.1 x64

2013-01-01 Thread Alexander Burger
Hi Mansur,

 I found this: 
 http://lists.freebsd.org/pipermail/freebsd-questions/2010-August/220250.html
 Maybe the problem is with system headers, that are not 32bit aware on FreeBSD 
 x64

Indeed. This describes quite well the possible reason of the problems.


 Btw, what about x64 version of picoLisp on FreeBSD? Is this possible
 and how I can help with it?

Good idea! We should try to get pil64 running then.

If the architecture is x86-64, we just need to extend src64/Makefile a
little (i.e. add a clause for 'FreeBSD', similar to the 'SunOS' stuff),
and create two new files

   src64/sys/x86-64.freeBsd.defs.l
   src64/sys/x86-64.freeBsd.code.l

The defs.l file can be generated pretty easily now, because since the
'emu' version we have a C-Programm 'src64/sysdefs' which prints most of
its contents ('emu' simply includes the standard output of that
program).

The code.l might be more difficult. It holds a set of stub functions
which are system dependent, and which can be found by compiling and
disassembling test programs in C, or perhaps by looking at the proper
macro expansions in the system's include files. So here some detective
work is necessary ;-)

♪♫ Alex
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


Re: picoLisp on FreeBSD 9.1 x64

2013-01-01 Thread Mansur Mamkin
ALT--LDu1Tujb1357058193
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64

CkhpIGFnYWluIQpmcm9twqBzeXMvd2FpdC5oOgoKI2RlZmluZT5fV1NUQVRVUyh4KTwtLS0+KF9X
X0lOVCh4KSAmIDAxNzcpCiNkZWZpbmU+X1dTVE9QUEVEPC0tLS0tPjAxNzc8LS0+PC0tLS0tLT4v
KiBfV1NUQVRVUyBpZiBwcm9jZXNzIGlzIHN0b3BwZWQgKi8KI2RlZmluZT5XSUZTVE9QUEVEKHgp
PC0+KF9XU1RBVFVTKHgpID09IF9XU1RPUFBFRCkKI2RlZmluZT5XU1RPUFNJRyh4KTwtLS0+KF9X
X0lOVCh4KSA+PiA4KQojZGVmaW5lPldJRlNJR05BTEVEKHgpPD4oX1dTVEFUVVMoeCkgIT0gX1dT
VE9QUEVEICYmIF9XU1RBVFVTKHgpICE9IDApCiNkZWZpbmU+V1RFUk1TSUcoeCk8LS0tPihfV1NU
QVRVUyh4KSkKI2RlZmluZT5XSUZFWElURUQoeCk8LS0+KF9XU1RBVFVTKHgpID09IDApCiNkZWZp
bmU+V0VYSVRTVEFUVVMoeCk8PihfV19JTlQoeCkgPj4gOCkKI2RlZmluZT5XSUZDT05USU5VRUQo
eCk+KHggPT0gMHgxMyk8LS0tPi8qIDB4MTMgPT0gU0lHQ09OVCAqLwoKCg==

ALT--LDu1Tujb1357058193
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64

CjxIVE1MPjxCT0RZPjxwPkhpIGFnYWluITxicj5mcm9tJm5ic3A7c3lzL3dhaXQuaDo8YnI+PGJy
PiNkZWZpbmUmZ3Q7X1dTVEFUVVMoeCkmbHQ7LS0tJmd0OyhfV19JTlQoeCkgJmFtcDsgMDE3Nyk8
YnI+I2RlZmluZSZndDtfV1NUT1BQRUQmbHQ7LS0tLS0mZ3Q7MDE3NyZsdDstLSZndDsmbHQ7LS0t
LS0tJmd0Oy8qIF9XU1RBVFVTIGlmIHByb2Nlc3MgaXMgc3RvcHBlZCAqLzxicj4jZGVmaW5lJmd0
O1dJRlNUT1BQRUQoeCkmbHQ7LSZndDsoX1dTVEFUVVMoeCkgPT0gX1dTVE9QUEVEKTxicj4jZGVm
aW5lJmd0O1dTVE9QU0lHKHgpJmx0Oy0tLSZndDsoX1dfSU5UKHgpICZndDsmZ3Q7IDgpPGJyPiNk
ZWZpbmUmZ3Q7V0lGU0lHTkFMRUQoeCkmbHQ7Jmd0OyhfV1NUQVRVUyh4KSAhPSBfV1NUT1BQRUQg
JmFtcDsmYW1wOyBfV1NUQVRVUyh4KSAhPSAwKTxicj4jZGVmaW5lJmd0O1dURVJNU0lHKHgpJmx0
Oy0tLSZndDsoX1dTVEFUVVMoeCkpPGJyPiNkZWZpbmUmZ3Q7V0lGRVhJVEVEKHgpJmx0Oy0tJmd0
OyhfV1NUQVRVUyh4KSA9PSAwKTxicj4jZGVmaW5lJmd0O1dFWElUU1RBVFVTKHgpJmx0OyZndDso
X1dfSU5UKHgpICZndDsmZ3Q7IDgpPGJyPiNkZWZpbmUmZ3Q7V0lGQ09OVElOVUVEKHgpJmd0Oyh4
ID09IDB4MTMpJmx0Oy0tLSZndDsvKiAweDEzID09IFNJR0NPTlQgKi88YnI+PGJyPjwvcD48YnI+
PHN0eWxlIHR5cGU9InRleHQvY3NzIj48L3N0eWxlPjwvQk9EWT48L0hUTUw+Cg==

ALT--LDu1Tujb1357058193--
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


Re: picoLisp on FreeBSD 9.1 x64

2013-01-01 Thread Alexander Burger
Hi Mansur,

 I added following lines In Makefile:
 ...
 ifeq ($(MAKECMDGOALS), x86-64.freeBsd)
 ...
 ifeq ($(UNAME), FreeBSD)
 ...

This looks all right.


 (.text+0x459): undefined reference to `stderr'

So this looks like 'stderr' etc. are not direct global variables, but
macros of some kind. For SunOS we have a similar case, so that
x86-64.sunOs.defs.l defines

   (equ stdin  $__iob)
   (equ stdout $__iob+128)
   (equ stderr $__iob+256)

Can you find out how 'stderr' is defined in the stdio includes?


 I don't know how to change x86-64.freeBsd.code.l
 I found this in man errno:
 extern int * __error();
 #define errno (* __error())

The Pil64 assembly code used the convention that the registers of the
arguments and return values of a function are encoded into the name. A
function 'fooAE_CXY' would expect arguments in 'A' and 'E', and return
values in 'C', 'X' and 'Y'.

Thus, the function 'errno_A' should return the error code in 'A'. From
your man errno above I would suspect that the correct implementation
is:

   (code 'errno_A 0)
  call __errno  # Get address of 'errno'
  ld4 (A)  # Load value
  ret

I.e. '__error()' corresponds to 'call __errno', and 'ld4' then fetches
an 'int' (a 4-byte value).

♪♫ Alex
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe