From ffjeld at common-lisp.net  Thu Sep  2 09:11:32 2004
From: ffjeld at common-lisp.net (Frode Vatvedt Fjeld)
Date: Thu, 02 Sep 2004 11:11:32 +0200
Subject: [movitz-devel] GDB-image [was Re: Procfs support for non-Allegro
	lisps?]
References: <caf8a68a04082400274a6a2740@mail.gmail.com>
Message-ID: <2hbrgp827v.fsf@vserver.cs.uit.no>

James Crippen <jcrippen at gmail.com> writes:

> Is there any procfs support in the works out there for non-Allegro
> lisps? I note that the procfs-image.lisp file uses a few functions
> from a PROCFS package that I presume is Allegro-specific. What would
> it take to get this working in other Lisps? It seems like it should
> be some not-overly-complicated file accessing after some pid lookup,
> right?

Come to think of it, I'd suggest if you're interested in lookin into
such debugging tools to rather consider writing a gdb-image (subclass
of movitz-image), where the GDB remote protocol is used to interface
the (emulated) machine running movitz. This should be even less
complicated than porting the procfs stuff to linux, and has many
advantages: better portability (across lisps and OSes), works with
QEMU, Bochs, and even actual hardware if only some GDB stub support is
added to the movitz image.

E.g: http://www.superhlinux.com/kgdb/gdbprotocol.php3

-- 
Frode Vatvedt Fjeld




From human at csufresno.edu  Sun Sep  5 23:19:58 2004
From: human at csufresno.edu (Elliott A Johnson)
Date: Sun, 05 Sep 2004 16:19:58 -0700
Subject: [movitz-devel] error during create-image with los0-gc.lisp
Message-ID: <1d79191d9f8b.1d9f8b1d7919@cvip.net>

Hi,

Just checking to see if anyone else is seeing this error when creating
an image?

   Type-error in KERNEL::OBJECT-NOT-LIST-ERROR-HANDLER:
     #:|cond-skip-0-85433| is not of type COMMON-LISP:LIST

Here's some more of the error message:

  (MOVITZ::ASSEMBLY-MACROEXPAND
   (:BOOLEAN-BRANCH-ON-FALSE . #:|cond-skip-0-85433|)
   #S(MOVITZ::ASSEMBLY-MACRO-ENVIRONMENT
        :EXPANDERS #<EQ hash table, 13 entries {496D23B5}>))
  Source: 
  ; File: /home/ejohnson/cvs-dir/movitz-cvs/movitz/assembly-syntax.lisp
  (LOOP FOR (P . TAIL) ON PRG ...)

Here's the first 10 backtraces from the error:

  0: (MOVITZ::ASSEMBLY-MACROEXPAND
      (:BOOLEAN-BRANCH-ON-FALSE . #:|cond-skip-0-85433|)
      #S(MOVITZ::ASSEMBLY-MACRO-ENVIRONMENT
           :EXPANDERS #<EQ hash table, 13 entries {496D23B5}>))
  1: (MOVITZ::ASSEMBLY-MACROEXPAND
      (:LOAD-LEXICAL
       #<MOVITZ::LOCATED-BINDING name: #:|interrupts-enabled-p-85428|
{4966532D}>
       (:BOOLEAN-BRANCH-ON-FALSE . #:|cond-skip-0-85433|))
      #S(MOVITZ::ASSEMBLY-MACRO-ENVIRONMENT
           :EXPANDERS #<EQ hash table, 13 entries {496D23B5}>))
  2: (MOVITZ::ASSEMBLY-MACROEXPAND
      (:SUB-PROGRAM (#:UNWIND-PROTECT-CLEANUP-ENTRY85431) (:LOAD-LEXICAL
# #)
       (:LOAD-CONSTANT # :EDX) (:MOVL # :ESI) ...)
      #S(MOVITZ::ASSEMBLY-MACRO-ENVIRONMENT
           :EXPANDERS #<EQ hash table, 13 entries {496D23B5}>))
  3: (MOVITZ::ASSEMBLY-MACROEXPAND
      '(:SUB-PROGRAM (#:UNWIND-PROTECT-CLEANUP-ENTRY85431)
(:LOAD-LEXICAL # #)
        (:LOAD-CONSTANT # :EDX) (:MOVL # :ESI) ...)
      #S(MOVITZ::ASSEMBLY-MACRO-ENVIRONMENT
           :EXPANDERS #<EQ hash table, 13 entries {496D23B5}>))
  4: (MOVITZ::ASSEMBLY-MACROEXPAND (:CALL '(:SUB-PROGRAM # # # # ...))
                                   #S(MOVITZ::ASSEMBLY-MACRO-ENVIRONMENT
                                        :EXPANDERS #<EQ hash table, 13
entries
                                                     {496D23B5}>))
  5: (MOVITZ::ASSEMBLY-MACROEXPAND ((:CALL '#))
                                   #S(MOVITZ::ASSEMBLY-MACRO-ENVIRONMENT
                                        :EXPANDERS #<EQ hash table, 13
entries
                                                     {496D23B5}>))
  6: (MOVITZ::ASSEMBLY-MACROEXPAND 2
                                   ((:CALL '#))
                                   #S(MOVITZ::ASSEMBLY-MACRO-ENVIRONMENT
                                        :EXPANDERS #<EQ hash table, 13
entries
                                                    
{496D23B5}>))[:EXTERNAL]
  7: (MOVITZ::SPECIAL-OPERATOR-WITH-INLINE-ASSEMBLY-CASE
      (WITH-INLINE-ASSEMBLY-CASE NIL (MOVITZ::DO-CASE # #))
      #<MOVITZ::MOVITZ-FUNOBJ-PASS1 STOP-AND-COPY {4963F325}>
      #<MOVITZ::WITH-THINGS-ON-STACK-ENV {496D1F0D}>
      #<unused-arg>
      ...)
  8: (MOVITZ::SPECIAL-OPERATOR-WITH-CLOAK
      (WITH-CLOAK (:MULTIPLE-VALUES # COMMON-LISP:T #)
       (WITH-INLINE-ASSEMBLY-CASE NIL #))
      #<MOVITZ::MOVITZ-FUNOBJ-PASS1 STOP-AND-COPY {4963F325}>
      #<MOVITZ::LET-ENV of STOP-AND-COPY binding
#:|interrupts-enabled-p-85428|
        {496562A5}>
      NIL
      ...)
  9: (MOVITZ::COMPILE-FORM
      (MULTIPLE-VALUE-PROG1 (WITH-PROGN-RESULTS # # # #)
       (WITH-INLINE-ASSEMBLY-CASE NIL #))
      #<MOVITZ::MOVITZ-FUNOBJ-PASS1 STOP-AND-COPY {4963F325}>
      #<MOVITZ::LET-ENV of STOP-AND-COPY binding
#:|interrupts-enabled-p-85428|
        {496562A5}>
      NIL
      ...)

I'm not exactly sure, but I'm thinking it could be a special-operator
problem.  I'm having a hard time wrapping my head around this one.  Any
thoughts as to what this actually is?

-Elliott



From ffjeld at common-lisp.net  Mon Sep  6 10:01:25 2004
From: ffjeld at common-lisp.net (Frode Vatvedt Fjeld)
Date: Mon, 06 Sep 2004 12:01:25 +0200
Subject: [movitz-devel] Re: error during create-image with los0-gc.lisp
References: <1d79191d9f8b.1d9f8b1d7919@cvip.net>
Message-ID: <2hpt4z67ii.fsf@vserver.cs.uit.no>

Elliott A Johnson <human at csufresno.edu> writes:

> Just checking to see if anyone else is seeing this error when creating
> an image?
>
>    Type-error in KERNEL::OBJECT-NOT-LIST-ERROR-HANDLER:
>      #:|cond-skip-0-85433| is not of type COMMON-LISP:LIST

AFAICT, the problem is a bug in CMUCL's loop, in that its
for-as-on-list fails to work on improper lists.

A simple work-around seems to be to declare (optimize (safety 0)).
I'm checking in a fix that does this, read-time conditionalized
on cmucl.


-- 
Frode Vatvedt Fjeld




From human at csufresno.edu  Mon Sep  6 10:34:02 2004
From: human at csufresno.edu (Elliott A Johnson)
Date: Mon, 06 Sep 2004 03:34:02 -0700
Subject: [movitz-devel] error during create-image with los0-gc.lisp
Message-ID: <1e43af1e347f.1e347f1e43af@cvip.net>

Frode-

I don't know if you "guarantee" Movitz to build on SBCL, but it suffers
from the same problem.

-Elliott


> +  #+cmu (declare (optimize (safety 0))) ; Circumvent CMUCL bug in
> loop for-as-on-list.
> +  (loop for (p . tail) on prg
> +      as expander = (and (consp p)
> +                         (symbolp (car p))
> +                         (assembly-macro-expander (car p) amenv))
> +      if expander
> +      append (funcall expander p) into result
> +      else if (consp p)
> +      append (list (assembly-macroexpand p amenv)) into result
> +      else append (list p) into result
> +      when (not (listp tail))
> +      do (setf (cdr (last result)) tail)
> +         (return result)
> +      finally (return result)))





From ffjeld at common-lisp.net  Mon Sep  6 11:58:37 2004
From: ffjeld at common-lisp.net (Frode Vatvedt Fjeld)
Date: Mon, 06 Sep 2004 13:58:37 +0200
Subject: [movitz-devel] Re: error during create-image with los0-gc.lisp
References: <1e43af1e347f.1e347f1e43af@cvip.net>
Message-ID: <2hhdqb6236.fsf@vserver.cs.uit.no>

Elliott A Johnson <human at csufresno.edu> writes:

> I don't know if you "guarantee" Movitz to build on SBCL, but it
> suffers from the same problem.

Indeed. Sigh. I'll make it #+(cmu sbcl), then.

-- 
Frode Vatvedt Fjeld




From ffjeld at common-lisp.net  Mon Sep  6 12:53:27 2004
From: ffjeld at common-lisp.net (Frode Vatvedt Fjeld)
Date: Mon, 06 Sep 2004 14:53:27 +0200
Subject: [movitz-devel] Re: error during create-image with los0-gc.lisp
References: <1e43af1e347f.1e347f1e43af@cvip.net>
Message-ID: <2h4qmb5zjs.fsf@vserver.cs.uit.no>

Elliott A Johnson <human at csufresno.edu> writes:

> I don't know if you "guarantee" Movitz to build on SBCL, but it
> suffers from the same problem.

Argh. It appears there's no easy work-around for sbcl. I've talked to
folks on #lisp and hopefully it'll be fixed, at least in CVS, soon.

-- 
Frode Vatvedt Fjeld




From human at csufresno.edu  Fri Sep 10 06:36:30 2004
From: human at csufresno.edu (Elliott A Johnson)
Date: Thu, 09 Sep 2004 23:36:30 -0700
Subject: [movitz-devel] A 32-bit read/write with
	%io-port-read/write-succession
Message-ID: <2c5d622cc37c.2cc37c2c5d62@cvip.net>

Hi guys,

I had a quick question about this function and its macro helper.  If I'm
understanding correctly, %io-port-write-succession would shift a 32-bit
number by a 2-bit offset, write 30bits, then write the unwritten 2-bits?

Is "io-port-w/r-succession" the preferable way of doing a 32-bit
transfer to registers, or is the shifting method Peter Minton used in
his harddisk LBA'ing preferable?

Thanks
-Elliott

ps- is this sort of 2 stage writing to registers ok?  I'd think most
synchronous read or writes would want to be performed in a single cycle?



From ffjeld at common-lisp.net  Fri Sep 10 11:32:18 2004
From: ffjeld at common-lisp.net (Frode Vatvedt Fjeld)
Date: Fri, 10 Sep 2004 13:32:18 +0200
Subject: [movitz-devel] Re: A 32-bit read/write with
	%io-port-read/write-succession
References: <2c5d622cc37c.2cc37c2c5d62@cvip.net>
Message-ID: <2hfz5q2wcd.fsf@vserver.cs.uit.no>

Elliott A Johnson <human at csufresno.edu> writes:

> I had a quick question about this function and its macro helper.  If I'm
> understanding correctly, %io-port-write-succession would shift a 32-bit
> number by a 2-bit offset, write 30bits, then write the unwritten
> 2-bits?

This is, if my memory and code-reading ability isn't totally warped,
incorrect. These operators deal purely with "raw" (untyped) data
quantities, i.e. 8, 16, or 32 bits, both in terms of main memory and
I/O-ports. So the object parameter is not type-checked in any way, and
you (the caller) had better be knowledgeable about its memory layout
etc.

> Is "io-port-w/r-succession" the preferable way of doing a 32-bit
> transfer to registers,

It should be the preferred way of transporting a block of data (such
as a network packet or disk block), most likely in the form of a lisp
array, to an I/O-port. An equivalent but less efficient alternative
would be to use io-port and memref (or aref for typed access to the
object) inside a loop. If you mean literally _a_ (one) transfer to an
I/O-port, just use the io-port operator.

This is how e.g. the read-succession operator should work (i.e. the
compiler-macro is just a hand-written assembly version of this code):

(defun %io-port-read-succession (port object offset start end byte-size)
  (cond
    ((eq :32-bit byte-size)
     (do ((i start (1+ i)))
         ((>= i end) object)
       (setf (memref object offset i :unsigned-byte32)
          (io-port port :unsigned-byte32))))
     ...))

The term "succession" btw I invented to mean a sequence/block of
untyped memory. Suggestions for better names are welcome. Perhaps
"memblock" or "memory-block" would be more easily understood?

> ps- is this sort of 2 stage writing to registers ok?  I'd think most
> synchronous read or writes would want to be performed in a single
> cycle?

Absolutely, such a 2-stage writing or reading would be unacceptable in
general, both for performance and functional reasons.

-- 
Frode Vatvedt Fjeld




From human at csufresno.edu  Sat Sep 11 08:11:46 2004
From: human at csufresno.edu (Elliott A Johnson)
Date: Sat, 11 Sep 2004 01:11:46 -0700
Subject: [movitz-devel] Re: A 32-bit read/write with
	%io-port-read/write-succession
Message-ID: <2f06482f172e.2f172e2f0648@cvip.net>

Frode wrote-
 
> This is, if my memory and code-reading ability isn't totally warped,
> incorrect. These operators deal purely with "raw" (untyped) data
> quantities, i.e. 8, 16, or 32 bits, both in terms of main memory and
> I/O-ports. So the object parameter is not type-checked in any way, and
> you (the caller) had better be knowledgeable about its memory layout
> etc.

Alrighty, thats way cooler than I thought it was :)  Thanks for the
explanation.  

> This is how e.g. the read-succession operator should work (i.e. the
> compiler-macro is just a hand-written assembly version of this code):

Frode, I don't know how busy you are, I assume you've got a lot on your
plate, but I'm just starting out with learning some asm in a processors
class and was wondering if you could explain some about what you did in
ia-x86?  Specifically, how it interfaces with lisp and what syntax
changes you settled on.  Any info would be cool :)
 
> The term "succession" btw I invented to mean a sequence/block of
> untyped memory. Suggestions for better names are welcome. Perhaps
> "memblock" or "memory-block" would be more easily understood?

Succession is totally appropriate for the function. My instincts say
"%io-group-read" or "%io-port-read-object" (etc.).  But the current
symbol should be fine, as long as the reader doesn't interpret it as
"secession", like only a half awake lame brain would ;) 

Thanks again Frode.



From ffjeld at common-lisp.net  Sun Sep 12 20:01:01 2004
From: ffjeld at common-lisp.net (Frode Vatvedt Fjeld)
Date: Sun, 12 Sep 2004 22:01:01 +0200
Subject: [movitz-devel] Re: A 32-bit read/write with
	%io-port-read/write-succession
References: <2f06482f172e.2f172e2f0648@cvip.net>
Message-ID: <2h3c1n2r5u.fsf@vserver.cs.uit.no>

Elliott A Johnson <human at csufresno.edu> writes:

> Frode, I don't know how busy you are, I assume you've got a lot on
> your plate, but I'm just starting out with learning some asm in a
> processors class and was wondering if you could explain some about
> what you did in ia-x86?  Specifically, how it interfaces with lisp
> and what syntax changes you settled on.  Any info would be cool :)

Obviously the CPU as such defines no syntax, but otherwise I made the
obvious choice (as others have in the past, certainly) to represent an
instruction stream as a list of instructions (lists) and labels
(symbols). The syntax is listed in BNF-form more or less in
ia-x86/read.lisp. There's not really any special "interfacing with
lisp", the instruction-streams (programs) are operated on as any other
sort of data.

-- 
Frode Vatvedt Fjeld