From chris at iBankTech.NET Tue Mar 16 02:12:48 2004 From: chris at iBankTech.NET (Chris Capel) Date: Mon, 15 Mar 2004 20:12:48 -0600 Subject: [movitz-devel] My experiences so far Message-ID: Hi everyone. I wanted to get involved, so I've been trying to get a lisp environment set up--I haven't really even gotten to trying to compile movitz yet. I'm trying to find a good IDE, which, it turns out, is a pretty daunting task. Eclipse would be nice, but doesn't have a mature lisp plugin. I haven't gotten Jabberwocky to run. So now I'm trying Emacs--specifically, Hemlock. The shift key doesn't work in X, but until that gets worked out, I'm going to just use the terminal interface. I don't want to bore anyone, but this list has been awefully quiet, and I didn't want Frode to be discouraged. Chris Capel -------------- next part -------------- An HTML attachment was scrubbed... URL: From tsiivola at cc.hut.fi Tue Mar 16 07:51:59 2004 From: tsiivola at cc.hut.fi (Nikodemus Siivola) Date: Tue, 16 Mar 2004 09:51:59 +0200 (EET) Subject: OT: Re: [movitz-devel] My experiences so far In-Reply-To: References: Message-ID: > compile movitz yet. I'm trying to find a good IDE, which, it turns out, Currently Slime + Emacs is a good bet. > Emacs--specifically, Hemlock. The shift key doesn't work in X, but > until that gets worked out, I'm going to just use the terminal Portable Hemlock or the CMUCL version? If the latter then I'd suggest asking cmucl-help for advice. Anyways, I'd definitely recommend Slime over Hemlock in a terminal -- unless you're interested in hacking the editor itself that is, in which case Hemlock is likely to be infinitely more rewarding. Cheers, -- Nikodemus From frodef at cs.uit.no Tue Mar 16 08:03:27 2004 From: frodef at cs.uit.no (Frode Vatvedt Fjeld) Date: Tue, 16 Mar 2004 09:03:27 +0100 Subject: [movitz-devel] Re: OT: Re: My experiences so far References: Message-ID: <2h1xntgqwg.fsf@vserver.cs.uit.no> Nikodemus Siivola writes: > Currently Slime + Emacs is a good bet. I think so too, also because there seems to be a movitz-slime.el in the works, presumably similar to my movitz-mode.el (which I suppose should be renamed movitz-eli.el, as it's very much bound to Franz ELI+Allegro). -- Frode Vatvedt Fjeld From chris at iBankTech.NET Tue Mar 16 13:08:21 2004 From: chris at iBankTech.NET (Chris Capel) Date: Tue, 16 Mar 2004 07:08:21 -0600 Subject: OT: [movitz-devel] My experiences so far Message-ID: >> compile movitz yet. I'm trying to find a good IDE, which, it turns out, >Currently Slime + Emacs is a good bet. I'll sure try it. >asking cmucl-help for advice. Anyways, I'd definitely recommend Slime over >Hemlock in a terminal -- unless you're interested in hacking the editor >itself that is, in which case Hemlock is likely to be infinitely more >rewarding. Hemlock would be a good starting place for an editor targeting Movitz, don't you think? It'd be nice if I didn't have to learn some other editor if I eventually wanted to hack Movitz while using Movitz. And for someone weaned on Visual Studio, Hemlock isn't quite as imposing. I mean, compare the size of the users' manuals. Heh. Chris Capel -------------- next part -------------- An HTML attachment was scrubbed... URL: From tsiivola at cc.hut.fi Tue Mar 16 13:31:58 2004 From: tsiivola at cc.hut.fi (Nikodemus Siivola) Date: Tue, 16 Mar 2004 15:31:58 +0200 (EET) Subject: OT: [movitz-devel] My experiences so far In-Reply-To: References: Message-ID: On Tue, 16 Mar 2004, Chris Capel wrote: > Hemlock would be a good starting place for an editor targeting Movitz, > don't you think? It'd be nice if I didn't have to learn some other > editor if I eventually wanted to hack Movitz while using Movitz. s/Hemlock/Portable Hemlock/ and you're probably right. There's been some talk of a merger between Goatee and Phemlock, though. Cheers, -- Nikodemus From a_bakic at yahoo.com Tue Mar 16 18:57:56 2004 From: a_bakic at yahoo.com (Aleksandar Bakic) Date: Tue, 16 Mar 2004 10:57:56 -0800 (PST) Subject: [movitz-devel] Re: OT: Re: My experiences so far In-Reply-To: <2h1xntgqwg.fsf@vserver.cs.uit.no> Message-ID: <20040316185756.97369.qmail@web40603.mail.yahoo.com> > I think so too, also because there seems to be a movitz-slime.el in > the works, presumably similar to my movitz-mode.el (which I suppose OK, here it is, works in my Emacs 21.2.1. I used the following file to test it (manually invoking add-movitz-key-bindings first). ---- (defpackage :fact (:use muerte.cl muerte)) (in-package :fact) (defmethod fact ((n t)) (if (= n 1) 1 (* n (fact (1- n))))) (defun hello-world () (format t "Hello, world!~%")) (defmacro foo (bar) `(format t "~A~%" ,bar)) ;;; (foo 123) ;;; (cl:loop for x upto 10 do (print 1)) ---- Alex ;;; -*- mode: emacs-lisp; mode: outline-minor; outline-regexp: ";;;;*"; indent-tabs-mode: nil -*- ;; movitz-slime.el -- Slime key bindings for Movitz, adapted from ;; movitz-mode.el by Frode Vatvedt Fjeld ;; Copyright (C) 2004 Aleksandar Bakic (defun add-movitz-key-bindings () (interactive "P") (slime-define-key "\M-\C-z\C-d" 'movitz-dump-image) (slime-define-key "\M-\C-z\C-v" 'movitz-disassemble-defun) (slime-define-key "\M-\C-z\C-b" 'movitz-compile-file) (slime-define-key "\M-\C-z\C-c" 'movitz-compile-defun) (slime-define-key "\M-\C-z\C-m" 'movitz-macroexpand) (slime-define-key "\M-\C-z\C-a" 'movitz-arglist)) (defun in-movitz-package-p () (let ((pkg (slime-buffer-package))) (and pkg (or (and (< 6 (length pkg)) (string= "MUERTE." (upcase (substring pkg 0 7)))) (member (upcase pkg) '("MUERTE" "X86" "X86-PC")))))) (defun movitz-defun-name-and-type () (interactive) (save-excursion (let ((definition-type (let ((x (buffer-substring-no-properties (progn (beginning-of-defun) (forward-char) (point)) (progn (forward-symbol 1) (point))))) (cond ((string-equal "defun" x) "function") ((string-match "^define-" x) (substring x 7)) ((string-match "^def" x) (substring x 3)) (t x)))) (definition-name (buffer-substring-no-properties (progn (forward-char) (point)) (progn (forward-sexp 1) (point)))) (lambda-list (buffer-substring-no-properties (progn (forward-char) (point)) (progn (forward-sexp 1) (point))))) (if (and (string-equal "method" definition-type) (char-equal 58 (string-to-char lambda-list))) (let ((qualifier lambda-list) ; one potential qualifier only (lambda-list (buffer-substring-no-properties (progn (forward-char) (point)) (progn (forward-sexp 1) (point))))) (values definition-name definition-type lambda-list (list qualifier))) (values definition-name definition-type lambda-list ""))))) (defun movitz-arglist (fname &optional show-fn) "Show the argument list for the nearest function call, if any. If SHOW-FN is non-nil, it is funcalled with the argument list instead of printing a message." (interactive (list (slime-read-symbol-name "Movitz arglist for: "))) (slime-eval-async `(cl:let ((funobj (movitz::movitz-env-named-function (cl:let ((cl:*package* (cl:find-package ,(make-symbol (concat ":" (slime-buffer-package)))))) (cl:read-from-string ,fname))))) (cl:if funobj (cl:format nil "~A" (movitz::movitz-print (movitz::movitz-funobj-lambda-list funobj))) "(-- )")) (slime-buffer-package) (with-lexical-bindings (show-fn fname) (lambda (arglist) (if show-fn (funcall show-fn arglist) (slime-background-message "%s" (slime-format-arglist fname arglist))))))) (defun movitz-dump-image (dont-run-bochs-p) "Dump a Movitz image." (interactive "P") (slime-background-message "Dumping a Movitz image...") (slime-eval-async '(movitz::dump-image) (slime-buffer-package) (with-lexical-bindings (dont-run-bochs-p) (slime-background-message "Dumping the Movitz image done. Bootblock ID: %d." (slime-eval 'movitz::*bootblock-build*)) (if dont-run-bochs-p t (slime-background-message "Running Bochs...") ;; assuming that bochsrc.txt is in the current directory and ;; boot disk is bound to los0-image file (call-process "/bin/sh" nil 0 nil "-c" "xterm -e bochs -q"))))) (defun movitz-compile-file () "Cross-compile buffer's file into movitz::*image*." (interactive) (movitz-compile-file* (buffer-file-name))) (defun movitz-compile-file* (file) "Cross-compile FILE into movitz::*image*." (save-some-buffers) (slime-background-message "Movitz compiling \"%s\"..." file) (slime-eval-async `(movitz::movitz-compile-file ,file) (slime-buffer-package) (with-lexical-bindings (file) (lambda (result) (slime-background-message "Movitz compiling \"%s\" done." file))))) (defun movitz-compile-defun (&optional inverse-optimize-p) "Cross-compile pointed function into movitz::*image*." (interactive "P") (multiple-value-bind (defun-name defun-type) (movitz-defun-name-and-type) (when defun-name (let ((pkg (format "(in-package %s)\n" (slime-buffer-package))) (fun (slime-defun-at-point)) (file (make-temp-name "/tmp/movitz-compile-defun-"))) (with-temp-file file (insert pkg fun)) (movitz-compile-defun* file defun-name defun-type inverse-optimize-p))))) (defun movitz-compile-defun* (file fname ftype invopt) "Cross-compile function of name FNAME and type FTYPE in FILE, with or without optimizations, then delete FILE." (slime-background-message "Movitz compiling %s %s..." ftype fname) (slime-eval-async `(cl:if ,invopt (cl:let ((movitz::*compiler-do-optimize* (cl:not movitz::*compiler-do-optimize*))) (movitz::movitz-compile-file ,file :delete-file-p t)) (movitz::movitz-compile-file ,file :delete-file-p t)) (slime-buffer-package) (with-lexical-bindings (fname ftype) (lambda (result) (slime-background-message "Movitz compiling %s %s done." ftype fname))))) (defun movitz-disassemble-defun (not-recursive-p) "Disassemble pointed function in movitz::*image*." (interactive "P") (multiple-value-bind (defun-name defun-type lambda-list options) (movitz-defun-name-and-type) (cond ((string= "function" defun-type) (slime-background-message "Movitz disassembling %s %s..." defun-type defun-name) (slime-eval-async `(cl:let ((defun-name (cl:let ((cl:*package* (cl:find-package ,(make-symbol (concat ":" (slime-buffer-package)))))) (cl:read-from-string ,defun-name))) (cl:*print-base* 16)) (movitz::movitz-disassemble defun-name :recursive ,(not not-recursive-p))) (slime-buffer-package) (with-lexical-bindings (defun-type defun-name) (lambda (result) (slime-background-message "Movitz disassembling %s %s done." defun-type defun-name))))) ((string= "method" defun-type) (slime-background-message "Movitz disassembling %s %s %s..." defun-type defun-name lambda-list) (slime-eval-async `(cl:let* ((method-name (cl:let ((cl:*package* (cl:find-package ,(make-symbol (concat ":" (slime-buffer-package)))))) (cl:read-from-string ,defun-name))) (gf (movitz::movitz-env-named-function method-name)) (qualifiers (cl:read-from-string ,options)) (lambda-list (cl:let ((cl:*package* (cl:find-package ,(make-symbol (concat ":" (slime-buffer-package)))))) (cl:read-from-string ,lambda-list))) (specializing-lambda-list (cl:subseq lambda-list 0 (cl:position-if (cl:lambda (x) (cl:and (cl:symbolp x) (cl:char= (cl:character '&) (cl:char (cl:string x) 0)))) lambda-list))) (specializers (cl:mapcar (cl:function muerte::find-specializer) (cl:mapcar (cl:lambda (x) (cl:if (cl:consp x) (cl:second x) 'muerte.cl:t)) specializing-lambda-list))) (method (muerte::movitz-find-method gf qualifiers specializers)) (funobj (muerte::movitz-slot-value method 'muerte::function)) (cl:*print-base* 16)) (movitz::movitz-disassemble-funobj funobj)) (slime-buffer-package) (with-lexical-bindings (defun-type defun-name lambda-list) (lambda (result) (slime-background-message "Movitz disassembling %s %s %s done." defun-type defun-name lambda-list))))) ((string= "primitive-function" defun-type) (slime-background-message "Movitz disassembling %s %s..." defun-type defun-name) (slime-eval-async nil (slime-buffer-package) (with-lexical-bindings (defun-type defun-name) (lambda (result) (slime-background-message "Movitz disassembling %s %s done." defun-type defun-name))))) (t (message "Don't know how to Movitz disassemble %s %s." defun-type defun-name))))) (defun movitz-macroexpand () "Macroexpand pointed s-expression." (interactive) (let ((sexp (slime-sexp-at-point)) (file (make-temp-name "/tmp/movitz-macroexpand-"))) (with-temp-file file (insert sexp)) (movitz-macroexpand* file))) (defun movitz-macroexpand* (file) "Macroexpand s-expression in FILE, then delete FILE." (slime-background-message "Movitz macroexpanding...") (slime-eval-async `(cl:with-output-to-string (cl:*standard-output*) (cl:let ((cl:*print-pretty* cl:t) (cl:*package* (cl:find-package ,(make-symbol (concat ":" (slime-buffer-package)))))) (cl:prin1 (movitz::translate-program (movitz::movitz-macroexpand-1 (cl:let ((cl:*package* (cl:find-package ,(make-symbol (concat ":" (slime-buffer-package)))))) (cl:with-open-file (stream ,file :direction :input) (cl:read stream)))) :common-lisp :muerte.common-lisp)))) (slime-buffer-package) (with-lexical-bindings (file) (lambda (result) (delete-file file) (slime-background-message "Movitz macroexpanding done.") (if (and (not (find 10 result)) (< (length result) 80)) (message "Movitz: %s" result) (let ((buffer (get-buffer-create "*Movitz Macroexpand*"))) (with-current-buffer buffer (delete-region 1 (point-max)) (lisp-mode) (insert result) (newline 2) (pop-to-buffer buffer)))))))) (load-library "cl-indent") (defun cl-indent (sym indent) ;; by Pierpaolo Bernardi (put sym 'common-lisp-indent-function (if (symbolp indent) (get indent 'common-lisp-indent-function) indent))) (cl-indent 'compiler-values 'with-open-file) (cl-indent 'compiler-values-list 'with-open-file) (cl-indent 'compiler-values-bind 'multiple-value-bind) (cl-indent 'compiler-values-list-bind 'multiple-value-bind) (cl-indent 'compiler-call 'make-instance) (cl-indent 'compiler-values-setq 'multiple-value-setq) (cl-indent 'named-integer-case 'with-slots) (cl-indent 'with-ne2000-io 'with-slots) (cl-indent 'vector-double-dispatch 'case) (cl-indent 'sequence-dispatch 'case) (cl-indent 'sequence-double-dispatch 'case) (cl-indent 'simple-stream-dispatch 'case) (cl-indent 'with-inline-assembly 'prog) (cl-indent 'with-inline-assembly-case 'prog) (cl-indent 'do-case 'prog) (cl-indent 'compiler-typecase 'case) (add-hook 'lisp-mode-hook 'turn-on-font-lock) (add-hook 'lisp-mode-hook (lambda () (setq lisp-indent-function 'common-lisp-indent-function))) (add-hook 'lisp-mode-hook (lambda () (when (in-movitz-package-p) (message "Switching to Movitz keymap.") (use-local-map (add-movitz-key-bindings))))) ;;; slime-movitz.el ends here __________________________________ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com From ffjeld at common-lisp.net Wed Mar 17 16:47:01 2004 From: ffjeld at common-lisp.net (ffjeld at common-lisp.net) Date: Wed, 17 Mar 2004 17:47:01 +0100 Subject: [movitz-devel] Re: OT: Re: My experiences so far In-Reply-To: <20040317161257.45137.qmail@web40611.mail.yahoo.com> (Aleksandar Bakic's message of "Wed, 17 Mar 2004 08:12:57 -0800 (PST)") References: <20040317161257.45137.qmail@web40611.mail.yahoo.com> Message-ID: <2hsmg7ctfe.fsf@vserver.cs.uit.no> Aleksandar Bakic writes: > Now, if you have a nice small Movitz-related task that would help me > learn more, just let me know. Well, there are in general two areas: Extending the ANSI-specified library, or adding hardware support. For the ANSI library part, for example sequences.lisp are lacking all the substitute functions completely. You can probably find tons of other operators lacking yourself. For the hardware support, I think the first order of business is support for scanning the PCI bus in some way, access PCI config space, etc. Or to add drivers/interface functions for the legacy hardware such as the floppy or IDE drives, or VGA graphics, even. -- Frode Vatvedt Fjeld From chris at iBankTech.NET Thu Mar 18 02:06:12 2004 From: chris at iBankTech.NET (Chris Capel) Date: Wed, 17 Mar 2004 20:06:12 -0600 Subject: [movitz-devel] Compiling Movitz Message-ID: I don't know if I missed something somewhere (or if I'm just revealing myself as a neophyte to OS programming/Common Lisp/Emacs), but here's my problem: I can get SLIME up (SLIME rules!) and call (load "load.lisp") from Emacs from the movitz directory, and it finishes. But I can't figure out how to dump an image. When I call the movitz-dump-image function, it complains about *image* not being defined. Did I miss a step somewhere? Oh, and SLIME beats ILISP with its little finger. Chris Capel -------------- next part -------------- An HTML attachment was scrubbed... URL: From a_bakic at yahoo.com Thu Mar 18 07:20:15 2004 From: a_bakic at yahoo.com (Aleksandar Bakic) Date: Wed, 17 Mar 2004 23:20:15 -0800 (PST) Subject: [movitz-devel] Compiling Movitz In-Reply-To: Message-ID: <20040318072015.52872.qmail@web40608.mail.yahoo.com> --- Chris Capel wrote: > [...] not being defined. Did I miss a step somewhere? Here is what I use with CMUCL: (load "load") (setq movitz::*compiler-compile-eval-whens* nil movitz::*compiler-compile-macro-expanders* nil) (movitz::create-image) (movitz::dump-image) However, the CVS repository seems to be missing a file that define function vector-type-tag, so movitz::create-image fails. Alex __________________________________ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com From boldyrev+nospam at cgitftp.uiggm.nsc.ru Wed Mar 17 02:10:15 2004 From: boldyrev+nospam at cgitftp.uiggm.nsc.ru (Ivan Boldyrev) Date: Wed, 17 Mar 2004 08:10:15 +0600 Subject: [movitz-devel] OT: Re: My experiences so far References: Message-ID: <7loki1x88g.ln2@ibhome.cgitftp.uiggm.nsc.ru> On 8685 day of my life Chris Capel wrote: > So now I'm trying Emacs--specifically, Hemlock. The shift key > doesn't work in X, but until that gets worked out, I'm going to just > use the terminal interface. Press Num Lock. Don't ask why :) -- Ivan Boldyrev Perl is a language where 2 x 2 is not equal to 4. From ffjeld at common-lisp.net Thu Mar 18 09:30:04 2004 From: ffjeld at common-lisp.net (Frode Vatvedt Fjeld) Date: Thu, 18 Mar 2004 10:30:04 +0100 Subject: [movitz-devel] Re: Compiling Movitz References: <20040318072015.52872.qmail@web40608.mail.yahoo.com> Message-ID: <2h7jxicxk3.fsf@vserver.cs.uit.no> Aleksandar Bakic writes: > However, the CVS repository seems to be missing a file that define > function vector-type-tag, so movitz::create-image fails. Sorry, I've been sloppy with my check-ins lately. I believe the check-ins I've just made should make things consistent. -- Frode Vatvedt Fjeld From chris at iBankTech.NET Fri Mar 19 00:33:03 2004 From: chris at iBankTech.NET (Chris Capel) Date: Thu, 18 Mar 2004 18:33:03 -0600 Subject: [movitz-devel] Self-referential functions Message-ID: Slightly OT, perhaps. Reading the sources, I noticed a *lot* of things like (defmacro defmacro and (defun eq (a b) (eq a b)) . How exactly does that work? It sort of boggles my mind, really. Is there a general explanation on the web somewhere for this technique, or could someone explain how it works in Muerte? Chris Capel -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at iBankTech.NET Fri Mar 19 00:49:56 2004 From: chris at iBankTech.NET (Chris Capel) Date: Thu, 18 Mar 2004 18:49:56 -0600 Subject: [movitz-devel] Compiling Movitz, symbol-function problem Message-ID: > Here is what I use with CMUCL: Thanks! That works for me. Now for something completely different. When I (now successfully) run bochs with the movitz image, (symbol-function 'do) returns an error, whereas in CMUCL it returns #. The hyperspec tells me Muerte's behavior is incorrect: symbol-function called on a macro (or a special operator) needs to return "an object of implementation-dependent nature and identity", not signal an error. You're probably aware of this, but I thought I'd point it out just in case. Chris Capel -------------- next part -------------- An HTML attachment was scrubbed... URL: From nyef at softhome.net Fri Mar 19 02:31:55 2004 From: nyef at softhome.net (Nyef) Date: Thu, 18 Mar 2004 21:31:55 -0500 Subject: [movitz-devel] Self-referential functions In-Reply-To: References: Message-ID: <20040319023154.GA29626@miyu.paradiesanalytics.com> On Thu, Mar 18, 2004 at 06:33:03PM -0600, Chris Capel wrote: > Slightly OT, perhaps. Reading the sources, I noticed a *lot* of things like > > (defmacro defmacro > > and > > (defun eq (a b) > (eq a b)) > > . How exactly does that work? It sort of boggles my mind, really. Is there a general explanation on the web somewhere for this technique, or could someone explain how it works in Muerte? Well, it is a little confusing unless you know what's going on. It's still a little confusing when you do know what's going on. The compiler knows how to open-code the function eq, that is, it will turn a reference to eq into the equivalent machine code inline. But you still need the function object to exist so that it can be funcalled, grabbed with symbol-function, function, etc. So what the definition does is tell the compiler to make a function object, called eq, that performs the eq operation. RPG mentions this same thing in Patterns Of Software about the Lisp implementation that his company wrote. Similarly, the defmacro form you mentioned is picked up by the -compiler- version of defmacro, which creates a macro function for the target system (and possibly another one for the host, since some Lisp code is written in such a way as to require it). Is this making sense? > Chris Capel --Alastair Bridgewater From chris at iBankTech.NET Fri Mar 19 03:55:37 2004 From: chris at iBankTech.NET (Chris Capel) Date: Thu, 18 Mar 2004 21:55:37 -0600 Subject: [movitz-devel] Self-referential functions Message-ID: Ahh! I saw the definitions of things like cons and cdr and car that were defined using the assembly macros, and I understood those. I sort of understood the defmacro macro. The piece I was missing was that the first compiler *directly* translated certain operators, like eq. But wait, doesn't it do the same for car? Why do you need an assembly definition of car and cdr but not eq? Ugh. Let my try to sort this out. Movitz has facilities for directly manipulating bits and bytes (binary-types package). Upon these, it builds facilities for translating x86 assembly into the binary opcodes (ia-x86 package). It defines basic operators in terms of these. But it doesn't need to define eq in binary? Oh, wait it does. I was just looking in the wrong place. In movitz/losp/muerte/basic-macros.lisp, eq is defined as a compiler macro. It's just that its defun is in equalp.lisp. Ha! So everything is defined, in the first compiler's lisp, down to the bit and byte level. In movitz/image.lisp, there resides code to make a binary bootable image out of all this. Its job is basically to expand the lisp code into assembly and then into binary machine language. Once this expansion is performed, you have defined the second, bootable, lisp. I think I'm getting this, but please someone correct me if I got something backwards. Chris Capel -----Original Message----- From: Nyef [mailto:nyef at softhome.net] Sent: Thu 3/18/2004 8:31 PM To: Chris Capel Cc: movitz-devel at common-lisp.net Subject: Re: [movitz-devel] Self-referential functions The compiler knows how to open-code the function eq, that is, it will turn a reference to eq into the equivalent machine code inline. But you still need the function object to exist so that it can be funcalled, grabbed with symbol-function, function, etc. So what the definition does is tell the compiler to make a function object, called eq, that performs the eq operation. RPG mentions this same thing in Patterns Of Software about the Lisp implementation that his company wrote. --Alastair Bridgewater -------------- next part -------------- An HTML attachment was scrubbed... URL: From ffjeld at common-lisp.net Fri Mar 19 08:54:44 2004 From: ffjeld at common-lisp.net (Frode Vatvedt Fjeld) Date: Fri, 19 Mar 2004 09:54:44 +0100 Subject: [movitz-devel] Re: Self-referential functions References: Message-ID: <2hr7vp9pyj.fsf@vserver.cs.uit.no> "Chris Capel" writes: > (defun eq (a b) > (eq a b)) Nyef's description is correct. I thought I'd add that I agree it's confusing, and I've thought about having a compiler-macro-call operator that "applies" a compiler-macro. I.e. so that (compiler-macro-call eq a b) is compiled exactly the same as (eq a b), except that the compiler would ensure that eq is open-coded somehow. This would increase readability, and guarantee e.g. that eq is never ever compiled as an unbounded recursive function, even if the eq compiler-macro was somehow lost. -- Frode Vatvedt Fjeld From ffjeld at common-lisp.net Fri Mar 19 09:10:18 2004 From: ffjeld at common-lisp.net (Frode Vatvedt Fjeld) Date: Fri, 19 Mar 2004 10:10:18 +0100 Subject: [movitz-devel] Re: Self-referential functions References: Message-ID: <2hn06d9p8l.fsf@vserver.cs.uit.no> "Chris Capel" writes: > Ugh. Let my try to sort this out. Movitz has facilities for > directly manipulating bits and bytes (binary-types package). It is mostly movitz/storage-types.lisp that uses binary-types. The major exception is movitz/image.lisp that defines the run-time context structure, here named movitz-constant-block. > Oh, wait it does. I was just looking in the wrong place. In > movitz/losp/muerte/basic-macros.lisp, eq is defined as a compiler > macro. It's just that its defun is in equalp.lisp. Ha! The compiler-macros and corresponding functions are typically not located together because really pretty much all the (compiler-) macros must be defined before you have a sane compilation environment for functions. So it's a bit of a mess, since I haven't really sorted this out in a really principled manner. > So everything is defined, in the first compiler's lisp, down to the > bit and byte level. In movitz/image.lisp, there resides code to > make a binary bootable image out of all this. Its job is basically > to expand the lisp code into assembly and then into binary machine > language. The bits and pieces of making code-vectors from lisp code is of course in movitz/compiler.lisp. The image stuff is really a two-stage process. First, a symbolic-image is constructed (by create-image). This is a big structure of the types defined in movitz/storage-types.lisp, and represents "symbolically" the movitz lisp-world. Then, you can "dump" the symbolic-image to a bootable file. This is what dump-image does, obviously. The same symbolic-image can be dumped many times. You work interactively with the symbolic-image: Re-compile and add functions, types, etc. as you do with interactive lisp programming. There are two other, more exotic variants of images. A stream-image is (typically) a previously dumped image on file that is read back in. A procfs-image, or really a bochs-image, is an image that accesses the state of a bochs running movitz. Neither of these supports interactive modification very much, but they support (static) introspection, and the bochs-image supports some introspection of dynamic state, e.g. backtrace. One goal is to have a new kind of image that talks over a tty or network connection to a running movitz (i.e. on actual hardware), so that there can be real interactive development. -- Frode Vatvedt Fjeld From ffjeld at common-lisp.net Fri Mar 19 09:15:28 2004 From: ffjeld at common-lisp.net (Frode Vatvedt Fjeld) Date: Fri, 19 Mar 2004 10:15:28 +0100 Subject: [movitz-devel] Re: Compiling Movitz, symbol-function problem References: Message-ID: <2hish19ozz.fsf@vserver.cs.uit.no> "Chris Capel" writes: > (symbol-function 'do) Macros are currently not supported very well outside the movitz (cross) compiler. There are two issues. At one point I did pack all the macro-expansion code with images. Then I removed it because I had trouble fitting the image within the 600K bootloader limit.. Then, there's there are some problems from the fact that movitz is a cross-compiler. I.e. some macroexpanders expect a "proper" execution environment that is more that can be expected of the movitz target environment so far. So there is some cleaning up to be done, here. For example, I don't think there's any backquote support on the movitz side, yet. Should the macro-expanders be compiled or not? Should compiler-macros be included too? I suppose they are of no use without a compiler. -- Frode Vatvedt Fjeld From ffjeld at common-lisp.net Mon Mar 29 15:18:33 2004 From: ffjeld at common-lisp.net (Frode Vatvedt Fjeld) Date: Mon, 29 Mar 2004 17:18:33 +0200 Subject: [movitz-devel] GC is here Message-ID: <2h8yhj3cmu.fsf@vserver.cs.uit.no> Since my latest check-ins, there is some basic GC support in Movitz, and included in the los0 image. There's a new file losp/muerte/scavenge.lisp that so far holds two functions. One maps a function over potential pointers in any heap area, while another maps similarly over a stack, starting "inside" and winding out. This is the way a stack must be scavenged in order to see what is code-vectors (from the call/ret assembly), and what are pointers. Conspicuously missing still is support for code-vectors to migrate in any way. There's another file losp/los0-gc.lisp, that implements the GC architecture that los0.img now uses. The central function here is stop-and-copy, which performs Cheney style copying GC. There is much room for improvement here both in terms of functionality and performance, but I think this here is a decent basis for further development, and to be able to check the "supports GC" feature column. One nice way to see all this in action, is to boot up los0.img (with bochs, unless you're lucky to have a PC with an ancient NE2000 NIC around) and start (ip4-test :10.0.0.10) and ping it. Ip4-test conses a new array for each ethernet frame it receives, so pretty soon you should be able to see the effects of the GC. (Of course, substitute 10.0.0.10 with some IPv4 address suitable for your LAN.) The GC incurs about 4.5 seconds delay under Bochs for me, while it's in the noise on real hardware with a 466MHz CPU. -- Frode Vatvedt Fjeld