<OriansJ>janneke: I am unfortunately breaking a few primitives in mes_posix.c to just get things into a happy state (But they should be an easy fix and are labeled as TODOs) <OriansJ>isatty isn't exactly a simple thing to express huh... <OriansJ>what possible purpose could we have for needing support for time in mes-m2? <janneke>OriansJ: yeah, isatty has been buggy until 0.19 even <janneke>m2-planet should be a able to copmile lib/posix/isatty.c? <janneke>but m2-planet may need to support the ioctl syscall for that <janneke>maybe we should postpone that and use --no-tty or something <janneke>OriansJ: the idea of supporting time was to measure performance <janneke>so i'm happy with a stub; m2-planet can use or add one to lib/stub/*.c ***ng0_ is now known as ng0
***ng0_ is now known as ng0
<OriansJ>janneke: so no harm in stripping time out of mes-m2 completely? <OriansJ>also looking at slow_lisp, why do you need isatty? <janneke>OriansJ: we can always bring it back when the need arises <janneke>OriansJ: you can also drop isatty -- because i need it anyway for the mes c lib, simply decided to use it for mes to create guile-like behaviour <janneke>decide wether to block on stdin, or startup the repl <OriansJ>or we could simply just simplify read to simply deal only with a single S-expression and then use a loop to keep it feed <OriansJ>that way there is no difference between REPL or reading a file <OriansJ>It also makes debugging the eval_apply alot easier too <dddddd>OriansJ, wrt the M2-Planet Aarch64 port, you wondered... """shouldn't the default a->depth be 32 not 16 as there should be 8 64bit pointers?""" Care to explain a bit, please? Do you mean for collect_local(), collect_arguments(), both? Which 8 pointers? <OriansJ>dddddd: in collect_local() the a->depth is the number of pointers times the size of pointers. For example x86 in main has 5 pointers by default and each is 4bytes and thus -20; but armv7l has 4 pointers by default and each is 4bytes and thus 16; if one has 4 pointers of 8bytes each, the total value should be 32 not 16 <OriansJ>for a call in M2-Planet on x86 there are 2 pointers and thus -8 but AMD64 also has 2 pointers but they are 64bits and thus -16 <OriansJ>the relationship is relative to the direct which the stack grows; for example: if(X86 == Architecture) a->depth = function->locals->depth - register_size; <OriansJ>verse if(KNIGHT_NATIVE == Architecture) a->depth = function->locals->depth + register_size; <dddddd>I count in 128 bits pushes, converted to bytes, to get offset from the BP. <dddddd>yes, I'm still using 128b pushes <OriansJ>dddddd: aarch64 should be 64bit pointers <dddddd>Anyway, from BP to the first local is only one push, so my default depth is 16. <OriansJ>as long as foo1(foo2(foo3(foo4,7), 6), 5) keeps working <dddddd>I don't see how 32 is the right default, even with 64b pushes <OriansJ>well there are the a->depth for main (which depends upon your libc) and the a->depth for the standard function call *xentrac is the right default <OriansJ>so if you look at void function_call(char* s, int bool) <dddddd>Yes, main has a special case in the code. <OriansJ>You do 2 pushes, then collect arguments <OriansJ>then you do a call that pushes the return upon the stack <dddddd>... but in the special case I'm not defaulting to 16 (the situation that triggered the question) <OriansJ>So the first address one could put a local is the 4 push location <dddddd>+ else if(AARCH64 == Architecture) a->depth = /* argc, argv, envp */ (16*3) + /* the local */ 16; <OriansJ>argc, argv, envp, return to _start, then locals <dddddd>hmm, maybe the code between the comments caused confusion? <OriansJ>if you look at test/common_amd64/libc-core.M1 <OriansJ>you see saving of rsp, putting argv in the stack, putting envp on the stack and then calling FUNCTION_main <OriansJ>then dealling with a program returning from main to _start (aka calling sys_exit) <OriansJ>and armv7l doesn't push the return upon the stack but rather puts it into the Link Register; which later has to be preserved and restored <OriansJ>hence the emit_out("{LR} PUSH_ALWAYS\t# Protect the old link register\n"); in function_call <OriansJ>and emit_out("{LR} POP_ALWAYS\t# Prevent overwrite\n"); after the call returned <OriansJ>hence the 2 register displacement between arguments and the first local variable <OriansJ>despite the fact that the call doesn't do a push but we were manually prior to the call itself <dddddd>I avoid one of those by protecting LR earlier <dddddd>The call to _start is similar in my libc-core.M1 <OriansJ>there is no avoiding it, the LR to return to _start needs to be saved prior to any calls to any other functions <dddddd>I mean, avoinding the extra offset, because I protect LR before get the BP-to-be (from SP) <dddddd>So LR is not stored in the stack between args and locals. <OriansJ>so it is just in the stack before args but because you didn't copy the new BP prior to setting it, it is "hidden" in terms of displacement <dddddd>I'll document the behaviour/layout and review my libc-core.M1 for unwanted asymmetry. Thanks!