Thank you Alex,
I can see how you would have to end up writing the whole thing in assembly
- in the example you shared. Would it be right to say that its only the
carry flag that you need or is it just an example and there are other flags
too? Can I say that the need is restricted to the use of
On Tue 29 Mar 2022 at 18:49, Alexander Burger wrote:
> As C does not allow access to the carry bit, you have to do ugly and
> inefficient
> tricks, by looking at the most significant bit of the result and trying to
> detect an overflow. For example, in bigAdd() in pil32's src/big.c:
>
>carry
Hi Kashyap,
>
> >> Pil32 and miniPicoLisp are written in C, and C does not support calling
> >> other functions in a generic way. This is one of the reasons pil64 was
> >> written in assembly (in addition to stack control and CPU status bits).
>
> Could you please throw some more light on the
Hey Alex,
I had reached out to you about the need for assembly in the past and
you had mentioned the following -
> 'c' implementation of pil32?
>> Pil32 and miniPicoLisp are written in C, and C does not support calling
>> other functions in a generic way. This is one of the reasons pil64 was
> On Mar 30, 2022, at 0:29, Alexander Burger wrote:
>
> As Pil64 is obsolete anyway, I strongly recommend to migrate to Pil64.
???
--
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/
--
UNSUBSCRIBE:
On Tue, Mar 29, 2022 at 05:29:02PM +0200, Alexander Burger wrote:
> As Pil64 is obsolete anyway, I strongly recommend to migrate to Pil64.
Oops!
Of course I wanted to say "... migrate to Pil21".
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Hi Morris,
> I might have encountered a bug related to
> (sect) and it's handling of NIL as element of
> the first passed list:
> ...
> A possibly related bug can be found with (diff):
> ...
Thanks for finding these bugs! I was not aware of them.
> I encountered this behavior on version 20.7.4
Hi Alex,
I might have encountered a bug related to (sect) and it's handling of
NIL as element of the first passed list:
: (sect (list NIL) NIL)
-> (NIL) # expected ()
It is not dependent on the second argument being the empty list:
: (sect (list 1 2 NIL 4) (list 2 3 4))
-> (2 NIL 4) #
