Hi Kevin,
> Previously, I've gotten pil21 (and originally pil64) to run bare metal on
> the RPI4 4/8 GB models.
> ...
> functionality, and adding some C/ASM for bootup and setting up the MMU and
> exception vectors, before branching to the pil21 interpreter loop (instead
>
> I wrote a small UART/
as
> Intel VM's.
>
> An aside: if one is executing on a 64-bit machine, how hard is it to
> execute a 32-bit 'application'? Can one easily start up a 32--bit thread
> inside a 64-bit machine?
>
> This 32 inside 64 question is purely theoretical (for the moment).
On Thu 31 Mar 2022 at 15:25, Henry Baker wrote:
> An aside: if one is executing on a 64-bit machine, how hard is it to
> execute a 32-bit 'application'? Can one easily start up a 32--bit
> thread inside a 64-bit machine? This 32 inside 64 question is
> purely theoretical (for the moment)...
I
purely theoretical (for the moment)...
-Original Message-
From:
Sent: Mar 31, 2022 2:59 AM
To:
Subject: Re: An assembly question from the past
On Wed, Mar 30, 2022 at 05:13:20PM -0700, C K Kashyap wrote:
> This may be of interest to you Henry - https://picolisp.com/wiki/?PilOS
Ri
On Wed, Mar 30, 2022 at 05:13:20PM -0700, C K Kashyap wrote:
> This may be of interest to you Henry - https://picolisp.com/wiki/?PilOS
Right, but it seems Henry looks for a 32-bit machine, but PilOS needs 64 bits.
☺/ A!ex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
0386/80486/80586 'bare metal'
> (or at least 'bare VM') -- talking directly to a HW serial port and reading
> from a FAT file system?
>
> -Original Message-
> From:
> Sent: Mar 30, 2022 10:38 AM
> To:
> Subject: Re: An assembly question from the pa
ystem?
-Original Message-
From:
Sent: Mar 30, 2022 10:38 AM
To:
Subject: Re: An assembly question from the past
On Wed, Mar 30, 2022 at 08:13:00AM -0700, C K Kashyap wrote:
> Just to give some background - I've been working on the attempt to port
> miniPicoLisp to window
> Good, but isn't miniPicoLisp plan vanilla C anyway? I think it uses only
> stdio
> library functions.
>
Thanks :Alex :) ... almost Vanilla C I think - with some gcc toppings (VLA
particularly) ;) I also moved away from pointer tagging in favor of an
extra "part" in the cell. This takes away any
On Wed, Mar 30, 2022 at 08:13:00AM -0700, C K Kashyap wrote:
> Just to give some background - I've been working on the attempt to port
> miniPicoLisp to windows (more like making vanilla C as the only
> dependency).
Good, but isn't miniPicoLisp plan vanilla C anyway? I think it uses only stdio
lib
Thanks for the clear explanation Alex,
Just to give some background - I've been working on the attempt to port
miniPicoLisp to windows (more like making vanilla C as the only
dependency). I wanted to make sure that I understood the cost of not going
with assembly. Since I use https://github.com/lib
Hi Kashyap,
> 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?
Pil64 used three flags (zero, sign and carry). CP
Hi Tomas,
> >carry = (unDig(src) & ~1) > num(setDig(dst, (unDig(src) & ~1) +
> > (unDig(dst) & ~1)));
> [...]
> > Concerning the stack, assembly code can handle the hardware stack pointer
> > just
> > like any other register.
>
> interesting
>
> Did you consider GCC inline assembly?
Yes.
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 Big
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
16 matches
Mail list logo
