freenode/#sicl - IRC Chatlog
Search
15:58:23
rpg
Can you make some kind of SICL-BOOT-OP that will be the main operation ? If so, we can control the context well enough to make this work.
15:58:23
beach
So that would break when I then try to use ASDF to build the code for the host, right?
15:59:08
rpg
If we have an identifiable phase (my SICL-BOOT-OP) that runs and then finishes, we can control the context, and make this work.
16:00:14
beach
Sure, I will start by doing (asdf:load-op "sicl-boot") and that's a normal host (SBCL) operation.
16:00:54
beach
As part of that code, I would like to say (asdf:....) which would then do the weird stuff.
16:01:26
beach
Once BOOT finishes, the next thing I will most likely do is a host (asdf:load-op ...) again.
16:02:09
rpg
I'm trying to think if we could have you do (asdf:operate-on-system 'sicl-boot-op "sicl-boot") -- but is that right?
16:02:55
rpg
And when you say after boot finishes you will probably do a host load-op again -- is "host" == vanilla SBCL or "host" == the SICL system.
16:03:51
beach
I don't need to configure (asdf:load-op "sicl-boot"). That's just compiling conforming Common Lisp code with SBCL.
16:04:28
beach
It is when I call (sicl-boo:boot) next, that I would like to call ASDF so that it loads things my way.
16:05:49
rpg
What I meant was you could have an ASDF system that describes the set of things that you would be loading as part of the boot process, and we could tailor this system's ASDF processing so that it sets up and tears down the context needed to modify the conventional load op.
16:06:55
beach
But I guess I don't understand why what I want to do is not precisely what ASDF says I should be able to do with a new operation and a method on PERFORM.
16:06:59
rpg
This world would have to interpret its dependencies as SICL boot dependencies, instead of conventional dependencies.
16:09:00
rpg
Yes, it might be that easy -- we define a SICL-BOOT-OP that requires SICL-LOAD-OP downwards and SICL-BOOT-OP sideways (as Fare uses those terms).
16:09:44
rpg
That would be cleaner, requiring no around methods, but requires thinking about ASDF dependencies.
16:10:12
rpg
"Downwards" == onto its components and "Sideways" is onto the components it depends on.
16:10:38
beach
I don't want to keep you from doing more important stuff. I can play with this a bit more myself.
16:11:45
rpg
1. Define a SICL-BOOT-OP, a SICL-LOAD-OP (I think that's the only operation. you need, right? You said no compilation...).
16:14:40
rpg
2. For SICL-LOAD-OP we need to tell ASDF that it depends on SICL-LOAD-OP being performed on its upstream members. Probably the easiest way to do this is to make SICL-LOAD-OP be a subclass of LOAD-OP, and make it *not* depend on COMPILE-OP on itself.
16:19:15
rpg
lisp-action.lisp has the definition of the operations for lisp files. So I think you make a subclass of load op (line 48 of lisp-action) that "selfward-depends" only on PREPARE-OP (standard LOAD-OP) depends on PREPARE-OP *and* COMPILE-OP
16:20:19
beach
Thanks for the hints. I'll work from here. If I need your help again, I'll let you know.
16:21:22
rpg
And... as I look at this, the PREPARE-OP (just a few lines up), requires LOAD-OP on its "sideways" depends. I guess you will need to replace that op, as well, with something that is like the built-in PREPARE-OP, but that requires SICL-LOAD-OP instead of LOAD-OP
16:22:15
rpg
That will be most of what you need -- you just need to make the PERFORM method for SICL-LOAD-OP, and I think (I hope!) you should be done.
16:23:11
rpg
There's a MAKE-PLAN (or some name like that) which will generate the plan structure for a system and an operation. building the plan and groveling over it will be easier for debugging that trying to apply the operation directly.
16:23:50
rpg
Getting the plan structure right is what you need to concentrate on, without being dragged into time consuming PERFORMs.
16:24:05
rpg
Once you get the plan built properly, you can add the PERFORM implementation and be done.
16:25:08
rpg
If you run into a dead end, you can reach me by email or on the asdf-devel mailing list. I'm not a regular on IRC any more, now that Slack is ruining my life.
2:49:45
no-defun-allowed
Hm, a STANDARD-OBJECT-CLASS-OF-INSTRUCTION has appeared in the MIR, and I assume it shouldn't because it would be replaced with a memory load.
3:10:25
no-defun-allowed
The next problem I have is that some lexical variable does not have an attribution, but is an input to an instruction. It is a NOOK-WRITE-INSTRUCTION somewhere in ROW-MAJOR-AREF, so I suppose I am getting somewhere still.
3:15:05
no-defun-allowed
Is there a convention for when to use MEMREF1 and an address addition or MEMREF2? I would guess the latter could only be implemented in one instruction when the offset is constant, on most RISC machines.
3:16:37
beach
I used to have only MEMREF1, but the MIR code because much bigger, and so did the code to generate it.
3:17:11
beach
The idea was to ultimately use "tiling", as suggested by scymtym, but that idea shall have to wait until later.