Unsubscribe

2019-01-21 Thread Alexander Matz
Good bye Alexander Matz  :-(
You are now unsubscribed



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


Re: Remove vla-member in anonymous bindFrame structs for clang compatibility

2018-08-09 Thread Alexander Matz
Hi Alex,

I think I misunderstood the whole architecture of picoLisp and shot of in the 
wrong direction.
The way I thought the picoLisp code is structured is that src is a common 
source and src64 is used in addition to src to build a 64bit version.

But it seems to be more like this:
src - 32bit version
src64 - 64bit version
  - ./arch ./sys define platforms and architectures
  - ./lib/asm.l defines an IR and implements an an IR -> ASM code generator 
ersatz - java implementation

in order to build the 64bit version or ersatz, you need a working picoLisp 
interpreter (any of the three works).

I'm on a x86-64 system, so in order to get the whole thing to work on mac I 
guess the most productive thing to do is to just skip everything 32bit and 
modify src64/sys/x86-64.linux.* (and find a workaround for the lack of 
-dumpspecs by clang).
Does that make sense?

Even though it would make the whole thread obsolete, the original problem 
(picolisp not working on macOS) would be solved if it works.

Thanks for all your help so far!
- Alex

> On 9. Aug 2018, at 18:18, Alexander Burger  wrote:
> 
> Hi Alex,
> 
>> Unfortunately, that crashes with "abort trap: 6", same for some other tests.
>> I'll see if I can find out what the issue is there.
> 
> Can it be that simply this single test fails?
> 
> test/lib.l, line 21
> 
>   ### abort ###
>   (test 6 (abort 2 (+ 1 2 3)))
> 
> giving an error like
> 
>   ((abort 2 (+ 1 2 3)))
>   6 -- 'test' failed
> 
> ☺ Alex
> 
> -- 
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


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


Re: Remove vla-member in anonymous bindFrame structs for clang compatibility

2018-08-09 Thread Alexander Matz
I have the hardware here somewhere or I could use a VM, I just need to set
up a test environment.

But thanks for the offer! :)

Manuel Cano  schrieb am Do., 9. Aug. 2018, 17:07:

> Hi,
>
> If you need a Linux machine I can create one account in one server for that


Re: Remove vla-member in anonymous bindFrame structs for clang compatibility

2018-08-09 Thread Alexander Matz
Hi Alex,

> On 9. Aug 2018, at 13:52, Alexander Burger  wrote:
> 
> Hi Alexander,
> 
>>  struct {
>>int vla[g()]; // vla-member, int array of size g()
>>  } s; 
>> The patch attached translates all uses of bindFrame as an anonymous struct
>> with a VLA-member to a combination of a regular byte-vla for memory and a
>> bindFrame pointer into that memory.
> 
> Cool! I was under the assumption that clang prohibits dynamically sized arrays
> in general, not just in structures. But when looking at your changes, using
> basically
> 
>   int bndLen = length(y)+2;
>   char fbuf[bindFrameSize(bndLen)];
> 
> instead of
> 
>   struct {  // bindFrame
>  struct bindFrame *link;
>  int i, cnt;
>  struct {any sym; any val;} bnd[length(y)+2];
>   } f;
> 
> I deduce that you still can use an dynamically sized array. After all, 
> length(y)
> is called at runtime.

Yes, that's 100% correct.
There's still a dynamically sized array allocated on the stack used, it's just 
outside of the struct definition.
As long as it's not a member of a struct, VLAs are a regular C99 feature and 
thankfully supported by all major compilers.
Clang also assumes C99 by default, so it works with your Makefiles out of the 
box.

> 
> 
>> This requires the bindFrame uses in question to use indirection, rendering 
>> the
>> patch a bit noisy.
> 
> Yes, and probably some runtime overhead due to the indirection (though the 
> same
> overhead must be there anyway, albeit hidden in the syntax).
> 

To be fair, I have no idea why the generated assembly differs at all.
In my opinion, the data layout should be exactly the same, especially since the 
line
"f.link = Env.bind, Env.bind = (bindFrame*)"
makes the struct visible to outside of the function and so the compiler 
shouldn't reorder fields or promote them to registers in either version of the 
code.

If I can get my hands on a nice PicoLisp benchmark and a linux machine I can 
use for that, I'd be happy to benchmark the whole thing.

> 
> 
>> As far as I'm aware and able to test, the behavior is identical.
> 
> Cool!
> 
> 
>> Overall the code is slightly shorter because the bindFrame struct is not
>> redefined as an anonymous struct 11 times throughout the code.
> 
> Well, but this is only the source code for the definitions, right? I expect it
> does not generate runtime code.
> 
> 
>> I'm not able to fully test everything because I'm struggling with the test
>> suite; I don't know whether this is due to me using macOS or misusing
>> PicoLisp.
> 
> Doesn't this
> 
>   $ ./pil lib/test.l -bye +
> 
> work? Sorry, I don't have a 32-bit system available any more.
> 
> Mike, how about you? I'm sure you are our absolute testing guru! ;)
> 

Unfortunately, that crashes with "abort trap: 6", same for some other tests.
I'll see if I can find out what the issue is there.

> 
>> The patch is generated from the git mirror but applies to the source in 
>> picoLisp-18.6.tgz
>> 
>> I'm happy about all feedback.
> 
> If it runs fine, I could release the patched files.

Sounds fantastic!

Cheers,
- Alex

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


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


Re: Remove vla-member in anonymous bindFrame structs for clang compatibility

2018-08-09 Thread Alexander Matz
Sorry for the double post, here's the godbolt link regarding the claim of very 
similar assembly: https://godbolt.org/g/uAJsRw

> On 9. Aug 2018, at 12:52, Alexander Matz  wrote:
> 
> Hi PicoLisp Community!
> 
> I'm working on a macOS system, where clang is the system compiler and so I'm 
> interested in getting PicoLisp to work there.
> The current code uses a barely documented, non-standard GCC extension, name 
> vla-members in structs inside of functions.
> This is a minimal demonstration of the feature:
> void f() {
>   struct {
> int vla[g()]; // vla-member, int array of size g()
>   } s; 
> }
> 
> This feature is not, and will not be, supported by clang, see 
> http://releases.llvm.org/6.0.0/tools/clang/docs/UsersManual.html 
> <http://releases.llvm.org/6.0.0/tools/clang/docs/UsersManual.html> unter 
> "Intentionally unsupported BCC extensions".
> VLA-Members is not to be confused with flexible array members (" 
> []" as the last member), which are a valid C99 feature.
> 
> The patch attached translates all uses of bindFrame as an anonymous struct 
> with a VLA-member to a combination of a regular byte-vla for memory and a 
> bindFrame pointer into that memory.
> This requires the bindFrame uses in question to use indirection, rendering 
> the patch a bit noisy.
> As far as I'm aware and able to test, the behavior is identical.
> The assembly generated by gcc is very similar, albeit slightly different.
> 
> Overall the code is slightly shorter because the bindFrame struct is not 
> redefined as an anonymous struct 11 times throughout the code.
> 
> I'm not able to fully test everything because I'm struggling with the test 
> suite; I don't know whether this is due to me using macOS or misusing 
> PicoLisp.
> Cursory tests were successful however.
> 
> The patch is generated from the git mirror but applies to the source in 
> picoLisp-18.6.tgz
> 
> I'm happy about all feedback.
> 
> Best Regards,
> Alexander Matz
> 
> <0001-no-vla-member-in-anonymous-bindFrame-clang-compatibi.patch>



Remove vla-member in anonymous bindFrame structs for clang compatibility

2018-08-09 Thread Alexander Matz
Hi PicoLisp Community!I'm working on a macOS system, where clang is the system compiler and so I'm interested in getting PicoLisp to work there.The current code uses a barely documented, non-standard GCC extension, name vla-members in structs inside of functions.This is a minimal demonstration of the feature:void f() {  struct {    int vla[g()]; // vla-member, int array of size g()  } s; }This feature is not, and will not be, supported by clang, see http://releases.llvm.org/6.0.0/tools/clang/docs/UsersManual.html unter "Intentionally unsupported BCC extensions".VLA-Members is not to be confused with flexible array members (" []" as the last member), which are a valid C99 feature.The patch attached translates all uses of bindFrame as an anonymous struct with a VLA-member to a combination of a regular byte-vla for memory and a bindFrame pointer into that memory.This requires the bindFrame uses in question to use indirection, rendering the patch a bit noisy.As far as I'm aware and able to test, the behavior is identical.The assembly generated by gcc is very similar, albeit slightly different.Overall the code is slightly shorter because the bindFrame struct is not redefined as an anonymous struct 11 times throughout the code.I'm not able to fully test everything because I'm struggling with the test suite; I don't know whether this is due to me using macOS or misusing PicoLisp.Cursory tests were successful however.The patch is generated from the git mirror but applies to the source in picoLisp-18.6.tgzI'm happy about all feedback.Best Regards,Alexander Matz

0001-no-vla-member-in-anonymous-bindFrame-clang-compatibi.patch
Description: Binary data


Subscribe

2018-08-09 Thread Alexander Matz
Hello Alexander Matz  :-)
You are now subscribed



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