headers
Frode Vatvedt Fjeld | 2 Sep 2004 11:11

GDB-image [was Re: Procfs support for non-Allegro lisps?]

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
Permalink | Reply | 0 comments |
headers
Elliott A Johnson | 6 Sep 2004 01:19
Picon

error during create-image with los0-gc.lisp

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
(Continue reading)

Permalink | Reply | 1 comment |
headers
Frode Vatvedt Fjeld | 6 Sep 2004 12:01

Re: error during create-image with los0-gc.lisp

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
Permalink | Reply | 0 comments |
headers
Elliott A Johnson | 6 Sep 2004 12:34
Picon

error during create-image with los0-gc.lisp

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)))
Permalink | Reply | 752 comments |
headers
Frode Vatvedt Fjeld | 6 Sep 2004 13:58

Re: error during create-image with los0-gc.lisp

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
Permalink | Reply | 0 comments |
headers
Frode Vatvedt Fjeld | 6 Sep 2004 14:53

Re: error during create-image with los0-gc.lisp

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
Permalink | Reply | 751 comments |
headers
Elliott A Johnson | 10 Sep 2004 08:36
Picon

A 32-bit read/write with %io-port-read/write-succession

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?
Permalink | Reply | 1 comment |
headers
Frode Vatvedt Fjeld | 10 Sep 2004 13:32

Re: A 32-bit read/write with %io-port-read/write-succession

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)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Elliott A Johnson | 11 Sep 2004 10:11
Picon

Re: Re: A 32-bit read/write with %io-port-read/write-succession

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 ;)
(Continue reading)

Permalink | Reply | 501 comments |
headers
Frode Vatvedt Fjeld | 12 Sep 2004 22:01

Re: A 32-bit read/write with %io-port-read/write-succession

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
Permalink | Reply | 501 comments |

Gmane