Re: [Factor-talk] Any way of making sense of what's in the boot image?
Thank you Alex. Seeing the polymorphic inline caching reference makes me
realize that I really need to go back and reread Slava's (et. al) various blogs
that have been produced through the years. I read them all once, but that was
a couple years ago -- not knowing what I know now. This should help me not
revisit ground in this forum that has already been documented elsewhere. A
bit more patience, everybody please, while I work out an effective (and
self-sufficient) internals exploration strategy.
> From: ajvond...@csupomona.edu
> To: factor-talk@lists.sourceforge.net
> Date: Fri, 17 Aug 2012 08:46:46 -0700
> Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
> image?
>
> pic-tail-reg = polymorphic inline cache tail call register
>
> ds-reg = data stack register
>
> rs-reg = retain stack register
>
> nv-reg: might help to see
> https://github.com/slavapestov/factor/blob/master/basis/cpu/x86/bootstrap.factor#L14
>
> link-reg: only place it seems to be used is
> https://github.com/slavapestov/factor/blob/master/basis/cpu/x86/bootstrap.factor#L49
>
> shift-arg, div-arg, mod-arg: seem to be used in x86 bootstrapping for holding
> arithmetic arguments; e.g.,
> https://github.com/slavapestov/factor/blob/master/basis/cpu/x86/bootstrap.factor#L561
>
> That's as much as I can gather from a glance,
> --Alex Vondrak
>
>
> From: Michael Clagett [mclag...@hotmail.com]
> Sent: Friday, August 17, 2012 7:08 AM
> To: Factor-Talk
> Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
> image?
>
> A few more:
>
> // ?
> : shift-arg ( -- reg ) ECX ;
>
> // ?
> : div-arg ( -- reg ) EAX ;
>
> // ?
> : mod-arg ( -- reg ) EDX ;
>
>
> ____________________
> From: mclag...@hotmail.com
> To: factor-talk@lists.sourceforge.net
> Date: Fri, 17 Aug 2012 14:03:30 +
> Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
> image?
>
> // ?
> : pic-tail-reg ( -- reg ) EDX ;
>
> // stack pointer
> : stack-reg ( -- reg ) ESP ;
>
> // stack frame pointer
> : frame-reg ( -- reg ) EBP ;
>
> // virtual machine object base
> : vm-reg ( -- reg ) EBX ;
>
> : ctx-reg ( -- reg ) EBP ;
>
> // non-volatile registers -- these would be registers needing to be
> preserved (and that callers can count on being preserved)?
> : nv-regs ( -- seq ) { ESI EDI EBX } ;
>
> // volatile registers -- these would be registers one is free to use (and
> that callers cannot count on being preserved)?
> : volatile-regs ( -- seq ) { EAX ECX EDX } ;
>
> // ?
> : nv-reg ( -- reg ) ESI ;
>
> // ?
> : ds-reg ( -- reg ) ESI ;
>
> // ?
> : rs-reg ( -- reg ) EDI ;
>
> // ?
> : link-reg ( -- reg ) EBX ;
>
> Would anybody be able to validate assumptions articulated above and fill in
> missing pieces. This is good foundational knowledge to operate in general
> with.
>
>
> From: mclag...@hotmail.com
> Date: Thu, 16 Aug 2012 13:15:48 -0400
> To: factor-talk@lists.sourceforge.net
> Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
> image?
>
> Great, thanks.
>
> Sent from my iPhone
>
> On Aug 16, 2012, at 1:11 PM, "John Benediktsson"
> mailto:mrj...@gmail.com>> wrote:
>
>
> So then, John, does that mean that in the [ 4 slot { array} declare ], that
> I'm getting the slot named "array" which is at offset 4 (and then declaring
> that to be an array, so as to disable some of the type safety checks)?
>
> Yes, the hashtable code is written at a bit lower level and thus maybe a
> little harder to read than one might normally write in Factor since it is one
> of the building blocks that everything is built upon. It is also possible
> that some of the compiler optimizations that have been written in the last
> couple of years make some of those declarations unnecessary, although I'd
> have to look into it more to know for sure.
>
> Also, due to the bootstrapping mechanism, some of the higher level language
> constructs like locals and fry quotations are not available yet. That is
> something we hope to fix at some future point.
>
> Here it says slot takes two incoming values: an obj and a non-negative
> fixnum, which is the nth slot. In the hashtable slot-specs you list below
> there are only three slots listed, but it does say that the slot named
> "array" is at offset 4. Is it this offset number that is being specified by
> the "m" parameter? And thus is
Re: [Factor-talk] Any way of making sense of what's in the boot image?
pic-tail-reg = polymorphic inline cache tail call register
ds-reg = data stack register
rs-reg = retain stack register
nv-reg: might help to see
https://github.com/slavapestov/factor/blob/master/basis/cpu/x86/bootstrap.factor#L14
link-reg: only place it seems to be used is
https://github.com/slavapestov/factor/blob/master/basis/cpu/x86/bootstrap.factor#L49
shift-arg, div-arg, mod-arg: seem to be used in x86 bootstrapping for holding
arithmetic arguments; e.g.,
https://github.com/slavapestov/factor/blob/master/basis/cpu/x86/bootstrap.factor#L561
That's as much as I can gather from a glance,
--Alex Vondrak
From: Michael Clagett [mclag...@hotmail.com]
Sent: Friday, August 17, 2012 7:08 AM
To: Factor-Talk
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot image?
A few more:
// ?
: shift-arg ( -- reg ) ECX ;
// ?
: div-arg ( -- reg ) EAX ;
// ?
: mod-arg ( -- reg ) EDX ;
From: mclag...@hotmail.com
To: factor-talk@lists.sourceforge.net
Date: Fri, 17 Aug 2012 14:03:30 +
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot image?
// ?
: pic-tail-reg ( -- reg ) EDX ;
// stack pointer
: stack-reg ( -- reg ) ESP ;
// stack frame pointer
: frame-reg ( -- reg ) EBP ;
// virtual machine object base
: vm-reg ( -- reg ) EBX ;
: ctx-reg ( -- reg ) EBP ;
// non-volatile registers -- these would be registers needing to be preserved
(and that callers can count on being preserved)?
: nv-regs ( -- seq ) { ESI EDI EBX } ;
// volatile registers -- these would be registers one is free to use (and that
callers cannot count on being preserved)?
: volatile-regs ( -- seq ) { EAX ECX EDX } ;
// ?
: nv-reg ( -- reg ) ESI ;
// ?
: ds-reg ( -- reg ) ESI ;
// ?
: rs-reg ( -- reg ) EDI ;
// ?
: link-reg ( -- reg ) EBX ;
Would anybody be able to validate assumptions articulated above and fill in
missing pieces. This is good foundational knowledge to operate in general with.
From: mclag...@hotmail.com
Date: Thu, 16 Aug 2012 13:15:48 -0400
To: factor-talk@lists.sourceforge.net
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot image?
Great, thanks.
Sent from my iPhone
On Aug 16, 2012, at 1:11 PM, "John Benediktsson"
mailto:mrj...@gmail.com>> wrote:
So then, John, does that mean that in the [ 4 slot { array} declare ], that I'm
getting the slot named "array" which is at offset 4 (and then declaring that to
be an array, so as to disable some of the type safety checks)?
Yes, the hashtable code is written at a bit lower level and thus maybe a little
harder to read than one might normally write in Factor since it is one of the
building blocks that everything is built upon. It is also possible that some
of the compiler optimizations that have been written in the last couple of
years make some of those declarations unnecessary, although I'd have to look
into it more to know for sure.
Also, due to the bootstrapping mechanism, some of the higher level language
constructs like locals and fry quotations are not available yet. That is
something we hope to fix at some future point.
Here it says slot takes two incoming values: an obj and a non-negative fixnum,
which is the nth slot. In the hashtable slot-specs you list below there are
only three slots listed, but it does say that the slot named "array" is at
offset 4. Is it this offset number that is being specified by the "m"
parameter? And thus is the array I am seeing in my original description the
contents of the "array" slot of the hashtable that was originally on the stack?
That makes sense to me. And the fact that the array is 128 slots long
(allowing flattened representation of 64 key-value pairs) just means that the
underlying array in the hashtable has 64 buckets. Is this a correct
interpretation. If it is, it makes sense that the actual 26 values stored in
the hash table would be dispersed throught the 64 buckets, because this is what
a hashtable does.
Yes, exactly! The "slot-spec" tuple provides a generic description of what is
to be found in this case at offset 4.
Best,
John.
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net<mailto:Factor-talk@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/factor-talk
-
Re: [Factor-talk] Any way of making sense of what's in the boot image?
A few more: // ?: shift-arg ( -- reg ) ECX ;
// ?: div-arg ( -- reg ) EAX ;
// ?: mod-arg ( -- reg ) EDX ;
From: mclag...@hotmail.com
To: factor-talk@lists.sourceforge.net
Date: Fri, 17 Aug 2012 14:03:30 +
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot image?
// ?
: pic-tail-reg ( -- reg ) EDX ;
// stack pointer
: stack-reg ( -- reg ) ESP ;
// stack frame pointer
: frame-reg ( -- reg ) EBP ;
// virtual machine object base
: vm-reg ( -- reg ) EBX ;
: ctx-reg ( -- reg ) EBP ;
// non-volatile registers -- these would be registers needing to be preserved
(and that callers can count on being preserved)?
: nv-regs ( -- seq ) { ESI EDI EBX } ;
// volatile registers -- these would be registers one is free to use (and that
callers cannot count on being preserved)?
: volatile-regs ( -- seq ) { EAX ECX EDX } ;
// ?
: nv-reg ( -- reg ) ESI ;
// ?
: ds-reg ( -- reg ) ESI ;
// ?
: rs-reg ( -- reg ) EDI ;
// ?
: link-reg ( -- reg ) EBX ;
Would anybody be able to validate assumptions articulated above and fill in
missing pieces. This is good foundational knowledge to operate in general with.
From: mclag...@hotmail.com
Date: Thu, 16 Aug 2012 13:15:48 -0400
To: factor-talk@lists.sourceforge.net
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
image?
Great, thanks.
Sent from my iPhone
On Aug 16, 2012, at 1:11 PM, "John Benediktsson" wrote:
So then, John, does that mean that in the [ 4 slot { array} declare ], that
I'm getting the slot named "array" which is at offset 4 (and then declaring
that to be an array, so as to disable some of the type safety checks)?
Yes, the hashtable code is written at a bit lower level and thus maybe a little
harder to read than one might normally write in Factor since it is one of the
building blocks that everything is built upon. It is also possible that some
of the compiler optimizations that have been written in the last couple of
years make some of those declarations unnecessary, although I'd have to look
into it more to know for sure.
Also, due to the bootstrapping mechanism, some of the higher level language
constructs like locals and fry quotations are not available yet. That is
something we hope to fix at some future point.
Here it says slot takes two incoming values: an obj and a non-negative
fixnum, which is the nth slot. In the hashtable slot-specs you list below
there are only three slots listed, but it does say that the slot named "array"
is at offset 4. Is it this offset number that is being specified by the "m"
parameter? And thus is the array I am seeing in my original description the
contents of the "array" slot of the hashtable that was originally on the stack?
That makes sense to me. And the fact that the array is 128 slots long
(allowing flattened representation of 64 key-value pairs) just means that the
underlying array in the hashtable has 64 buckets. Is this a correct
interpretation. If it is, it makes sense that the actual 26 values stored in
the hash table would be dispersed throught the 64 buckets, because this is what
a hashtable does.
Yes, exactly! The "slot-spec" tuple provides a generic description of what is
to be found in this case at offset 4.
Best,
John.
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats.
http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_
Re: [Factor-talk] Any way of making sense of what's in the boot image?
: pic-tail-reg ( -- reg ) EDX ;
//stack pointer // ?: stack-reg ( -- reg ) ESP ;
// stack frame pointer: frame-reg ( -- reg ) EBP ;
// virtual machine object base: vm-reg ( -- reg ) EBX ;
: ctx-reg ( -- reg ) EBP ;
// non-volatile registers -- these would be registers needing to be preserved
(and that callers can count on being preserved)?: nv-regs ( -- seq ) { ESI EDI
EBX } ;
// volatile registers -- these would be registers one is free to use (and that
callers cannot count on being preserved)?: volatile-regs ( -- seq ) { EAX ECX
EDX } ;
// ?: nv-reg ( -- reg ) ESI ;
// ?: ds-reg ( -- reg ) ESI ;
// ?: rs-reg ( -- reg ) EDI ;
// ?: link-reg ( -- reg ) EBX ; Would anybody be able to validate
assumptions articulated above and fill in missing pieces. This is good
foundational knowledge to operate in general with.
From: mclag...@hotmail.com
Date: Thu, 16 Aug 2012 13:15:48 -0400
To: factor-talk@lists.sourceforge.net
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
image?
Great, thanks.
Sent from my iPhone
On Aug 16, 2012, at 1:11 PM, "John Benediktsson" wrote:
So then, John, does that mean that in the [ 4 slot { array} declare ], that
I'm getting the slot named "array" which is at offset 4 (and then declaring
that to be an array, so as to disable some of the type safety checks)?
Yes, the hashtable code is written at a bit lower level and thus maybe a little
harder to read than one might normally write in Factor since it is one of the
building blocks that everything is built upon. It is also possible that some
of the compiler optimizations that have been written in the last couple of
years make some of those declarations unnecessary, although I'd have to look
into it more to know for sure.
Also, due to the bootstrapping mechanism, some of the higher level language
constructs like locals and fry quotations are not available yet. That is
something we hope to fix at some future point.
Here it says slot takes two incoming values: an obj and a non-negative
fixnum, which is the nth slot. In the hashtable slot-specs you list below
there are only three slots listed, but it does say that the slot named "array"
is at offset 4. Is it this offset number that is being specified by the "m"
parameter? And thus is the array I am seeing in my original description the
contents of the "array" slot of the hashtable that was originally on the stack?
That makes sense to me. And the fact that the array is 128 slots long
(allowing flattened representation of 64 key-value pairs) just means that the
underlying array in the hashtable has 64 buckets. Is this a correct
interpretation. If it is, it makes sense that the actual 26 values stored in
the hash table would be dispersed throught the 64 buckets, because this is what
a hashtable does.
Yes, exactly! The "slot-spec" tuple provides a generic description of what is
to be found in this case at offset 4.
Best,
John.
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats.
http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's securi
Re: [Factor-talk] Any way of making sense of what's in the boot image?
Great, thanks.
Sent from my iPhone
On Aug 16, 2012, at 1:11 PM, "John Benediktsson" wrote:
>
> So then, John, does that mean that in the [ 4 slot { array} declare ], that
> I'm getting the slot named "array" which is at offset 4 (and then declaring
> that to be an array, so as to disable some of the type safety checks)?
>
> Yes, the hashtable code is written at a bit lower level and thus maybe a
> little harder to read than one might normally write in Factor since it is one
> of the building blocks that everything is built upon. It is also possible
> that some of the compiler optimizations that have been written in the last
> couple of years make some of those declarations unnecessary, although I'd
> have to look into it more to know for sure.
>
> Also, due to the bootstrapping mechanism, some of the higher level language
> constructs like locals and fry quotations are not available yet. That is
> something we hope to fix at some future point.
>
> Here it says slot takes two incoming values: an obj and a non-negative
> fixnum, which is the nth slot. In the hashtable slot-specs you list below
> there are only three slots listed, but it does say that the slot named
> "array" is at offset 4. Is it this offset number that is being specified by
> the "m" parameter? And thus is the array I am seeing in my original
> description the contents of the "array" slot of the hashtable that was
> originally on the stack? That makes sense to me. And the fact that the
> array is 128 slots long (allowing flattened representation of 64 key-value
> pairs) just means that the underlying array in the hashtable has 64 buckets.
> Is this a correct interpretation. If it is, it makes sense that the actual
> 26 values stored in the hash table would be dispersed throught the 64
> buckets, because this is what a hashtable does.
>
> Yes, exactly! The "slot-spec" tuple provides a generic description of what
> is to be found in this case at offset 4.
>
>
> Best,
> John.
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> Factor-talk mailing list
> Factor-talk@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/factor-talk
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Any way of making sense of what's in the boot image?
> So then, John, does that mean that in the [ 4 slot { array} declare ],
> that I'm getting the slot named "array" which is at offset 4 (and then
> declaring that to be an array, so as to disable some of the type safety
> checks)?
>
Yes, the hashtable code is written at a bit lower level and thus maybe a
little harder to read than one might normally write in Factor since it is
one of the building blocks that everything is built upon. It is also
possible that some of the compiler optimizations that have been written in
the last couple of years make some of those declarations unnecessary,
although I'd have to look into it more to know for sure.
Also, due to the bootstrapping mechanism, some of the higher level language
constructs like locals and fry quotations are not available yet. That is
something we hope to fix at some future point.
> Here it says slot takes two incoming values: an obj and a non-negative
> fixnum, which is the nth slot. In the hashtable slot-specs you list below
> there are only three slots listed, but it does say that the slot named
> "array" is at offset 4. Is it this offset number that is being specified
> by the "m" parameter? And thus is the array I am seeing in my original
> description the contents of the "array" slot of the hashtable that was
> originally on the stack? That makes sense to me. And the fact that the
> array is 128 slots long (allowing flattened representation of 64 key-value
> pairs) just means that the underlying array in the hashtable has 64
> buckets. Is this a correct interpretation. If it is, it makes sense that
> the actual 26 values stored in the hash table would be dispersed
> throught the 64 buckets, because this is what a hashtable does.
>
Yes, exactly! The "slot-spec" tuple provides a generic description of what
is to be found in this case at offset 4.
Best,
John.
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Any way of making sense of what's in the boot image?
So then, John, does that mean that in the [ 4 slot { array} declare ], that I'm
getting the slot named "array" which is at offset 4 (and then declaring that to
be an array, so as to disable some of the type safety checks)? slot ( obj m
-- value )
Vocabulary
slots.privateInputs and outputs
obj an object
m a non-negative fixnum
value an object Word description
Reads the object stored at the nth slot of obj.
Here it says slot takes two incoming values: an obj and a non-negative fixnum,
which is the nth slot. In the hashtable slot-specs you list below there are
only three slots listed, but it does say that the slot named "array" is at
offset 4. Is it this offset number that is being specified by the "m"
parameter? And thus is the array I am seeing in my original description the
contents of the "array" slot of the hashtable that was originally on the stack?
That makes sense to me. And the fact that the array is 128 slots long
(allowing flattened representation of 64 key-value pairs) just means that the
underlying array in the hashtable has 64 buckets. Is this a correct
interpretation. If it is, it makes sense that the actual 26 values stored in
the hash table would be dispersed throught the 64 buckets, because this is what
a hashtable does. So am I understanding this correctly? By the way, the words
you pointed me to are exceedingly useful, thank you very much. I hate to be so
needy, but this is foundational stuff that will help me immensely with my task
(which should produce documentation goodies for the entire community).
From: mrj...@gmail.com
Date: Thu, 16 Aug 2012 08:10:31 -0700
To: factor-talk@lists.sourceforge.net
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
image?
In the listener, if you run this code:
IN: scratchpad clearIN: scratchpad "value" "key" associate
Then step over to [ set-at ] keep
If at this point you just keep stepping "into" things, you should do a deep
dive into all the parts, including the 4 slot { array } declare which should
give you something like { ~tombstone~ ~tombstone~ ~tombstone~ ~tombstone~ } (an
array full of "tombstone" elements which indicate no key or value is present).
A hashtable with deleted elements will have "~empty~". A hashtable with
key/value will have { "key" "value" } at some point in the array. The array is
flattened key/value pairs, so a 4 bucket hashtable will have an 8 element array
storing key/value side-by-side starting at the even indices.
I'm not sure what the 26-slot hash table is that you are looking at, so I put a
clear in the code above to make sure your data stack is empty before walking.
It is also possible that you are tracing some code which is traversing the
namespaces (a vector of hashtables containing symbolic variables used in parts
of the code, with names like the ones you mention).
A hashtable has 3 slots (the 0 slot is a numeric value), see:
```IN: scratchpad \ hashtable "slots" word-prop .{T{ slot-spec
{ name "count" }{ offset 2 }{ class array-capacity }
{ initial 0 }}T{ slot-spec{ name "deleted" }
{ offset 3 }{ class array-capacity }{ initial 0 }}
T{ slot-spec{ name "array" }{ offset 4 }
{ class array }{ initial { } }}}```
You might also like to try "describe", and poke around at the various word
properties (see "props" below):
```IN: scratchpad \ hashtable describeIN: hashtables SYMBOL: hashtablehashcode
251442479911733628name "hashtable"vocabulary"hashtables"
def [ \ hashtable ]props H{ { "help-parent" "hashtables" } {
"slots" ~array~ } { ...pic-def fpic-tail-def fsub-primitive f
```
On Thu, Aug 16, 2012 at 6:01 AM, Michael Clagett wrote:
Hi --
Okay. I'm going to ask for my first lifeline. :) I'm tracing through some
arcane stuff indeed. Everything is going along swimmingly. I get to the word
"new-key@", which at its start wants to execute [ array>> 2dup hash@ 0 f
(new-key@) ] with the "keep" combinator. All good so far. "array>>" resolves
to [ 4 slot { array } declare ], which I believe should mean "get the 4th slot
of the object on top of stack and declare to Factor that you know for sure it
is an array". The object on the top of the stack, according to the Inspector,
is a 26-slot hash table that includes such keys as "architecture", "auto-use?",
"bootstrap-syntax", "bootsrapping?", etc.
Now comes the part that baffles me. When I get to executing "slot" (whether I
try to step past it o
Re: [Factor-talk] Any way of making sense of what's in the boot image?
Btw, you might be wondering why you can't step "into" the slot word:
If you look at it, it's a primitive, meaning implemented in the VM C++ code
or a compiler intrinsic:
```
IN: scratchpad \ slot see
IN: slots.private
PRIMITIVE: slot ( obj m -- value ) flushable
```
In this case, I believe it is emitted by 'cpu.x86.bootstrap`:
```
[
! load slot number
temp0 ds-reg [] MOV
! adjust stack pointer
ds-reg bootstrap-cell SUB
! load object
temp1 ds-reg [] MOV
! turn slot number into offset
fixnum>slot@
! mask off tag
temp1 tag-bits get SHR
temp1 tag-bits get SHL
! load slot value
temp0 temp1 temp0 [+] MOV
! push to stack
ds-reg [] temp0 MOV
] \ slot define-sub-primitive
```
There are compiler intrinsics you can look at in compiler.cfg.intrinsics if
that interests you.
An example of a primitive VM word might be something like bignum-gcd, which
is defined in vm/math.cpp, pops two bignums from the stack and then
computes their GCD in C++ code and then pushes the result back onto the
stack.
```
void factor_vm::primitive_bignum_gcd()
{
POP_BIGNUMS(x,y);
ctx->push(tag(bignum_gcd(x,y)));
}
```
The mapping is defined in core/bootstrap/primitives.factor
```
{
...
{ "bignum-gcd" "math.private" "primitive_bignum_gcd" ( x y -- z ) }
...
}
[ first4 make-primitive ] each
```
On Thu, Aug 16, 2012 at 8:18 AM, Michael Clagett wrote:
> Wow. Great, John! Thanks. This should keep me at bay for a good while.
>
> --
> From: mrj...@gmail.com
> Date: Thu, 16 Aug 2012 08:10:31 -0700
>
> To: factor-talk@lists.sourceforge.net
> Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
> image?
>
> In the listener, if you run this code:
>
> IN: scratchpad clear
> IN: scratchpad "value" "key" associate
>
> Then step over to [ set-at ] keep
>
> If at this point you just keep stepping "into" things, you should do a
> deep dive into all the parts, including the 4 slot { array } declare which
> should give you something like {
> ~tombstone~ ~tombstone~ ~tombstone~ ~tombstone~ } (an array full of
> "tombstone" elements which indicate no key or value is present). A
> hashtable with deleted elements will have "~empty~". A hashtable with
> key/value will have { "key" "value" } at some point in the array. The
> array is flattened key/value pairs, so a 4 bucket hashtable will have an 8
> element array storing key/value side-by-side starting at the even indices.
>
> I'm not sure what the 26-slot hash table is that you are looking at, so I
> put a clear in the code above to make sure your data stack is empty before
> walking. It is also possible that you are tracing some code which is
> traversing the namespaces (a vector of hashtables containing symbolic
> variables used in parts of the code, with names like the ones you mention).
>
> A hashtable has 3 slots (the 0 slot is a numeric value), see:
>
> ```
> IN: scratchpad \ hashtable "slots" word-prop .
> {
> T{ slot-spec
> { name "count" }
> { offset 2 }
> { class array-capacity }
> { initial 0 }
> }
> T{ slot-spec
> { name "deleted" }
> { offset 3 }
> { class array-capacity }
> { initial 0 }
> }
> T{ slot-spec
> { name "array" }
> { offset 4 }
> { class array }
> { initial { } }
> }
> }
> ```
>
> You might also like to try "describe", and poke around at the various word
> properties (see "props" below):
>
> ```
> IN: scratchpad \ hashtable describe
> IN: hashtables SYMBOL: hashtable
> hashcode 251442479911733628
> name "hashtable"
> vocabulary"hashtables"
> def [ \ hashtable ]
> props H{ { "help-parent" "hashtables" } { "slots" ~array~ } { ...
> pic-def f
> pic-tail-def f
> sub-primitive f
> ```
>
>
> On Thu, Aug 16, 2012 at 6:01 AM, Michael Clagett wrote:
>
> Hi --
>
> Okay. I'm going to ask for my first lifeline. :) I'm tracing through
> some arcane stuff indeed. Everything is going along swimmingly. I get to
> the word "new-key@", which at its start wants to execute [ array>> 2dup
> hash@ 0 f (new-key@) ] with the "keep" combinator. All good so far.
> "array>>" resolves to [ 4 slot { array } declare ], which I believe should
> mean "get the 4th slot of the object on top of stack and declare to Factor
> that you know for s
Re: [Factor-talk] Any way of making sense of what's in the boot image?
Wow. Great, John! Thanks. This should keep me at bay for a good while.
From: mrj...@gmail.com
Date: Thu, 16 Aug 2012 08:10:31 -0700
To: factor-talk@lists.sourceforge.net
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
image?
In the listener, if you run this code:
IN: scratchpad clearIN: scratchpad "value" "key" associate
Then step over to [ set-at ] keep
If at this point you just keep stepping "into" things, you should do a deep
dive into all the parts, including the 4 slot { array } declare which should
give you something like { ~tombstone~ ~tombstone~ ~tombstone~ ~tombstone~ } (an
array full of "tombstone" elements which indicate no key or value is present).
A hashtable with deleted elements will have "~empty~". A hashtable with
key/value will have { "key" "value" } at some point in the array. The array is
flattened key/value pairs, so a 4 bucket hashtable will have an 8 element array
storing key/value side-by-side starting at the even indices.
I'm not sure what the 26-slot hash table is that you are looking at, so I put a
clear in the code above to make sure your data stack is empty before walking.
It is also possible that you are tracing some code which is traversing the
namespaces (a vector of hashtables containing symbolic variables used in parts
of the code, with names like the ones you mention).
A hashtable has 3 slots (the 0 slot is a numeric value), see:
```IN: scratchpad \ hashtable "slots" word-prop .{T{ slot-spec
{ name "count" }{ offset 2 }{ class array-capacity }
{ initial 0 }}T{ slot-spec{ name "deleted" }
{ offset 3 }{ class array-capacity }{ initial 0 }}
T{ slot-spec{ name "array" }{ offset 4 }
{ class array }{ initial { } }}}```
You might also like to try "describe", and poke around at the various word
properties (see "props" below):
```IN: scratchpad \ hashtable describeIN: hashtables SYMBOL: hashtablehashcode
251442479911733628name "hashtable"vocabulary"hashtables"
def [ \ hashtable ]props H{ { "help-parent" "hashtables" } {
"slots" ~array~ } { ...pic-def fpic-tail-def fsub-primitive f
```
On Thu, Aug 16, 2012 at 6:01 AM, Michael Clagett wrote:
Hi --
Okay. I'm going to ask for my first lifeline. :) I'm tracing through some
arcane stuff indeed. Everything is going along swimmingly. I get to the word
"new-key@", which at its start wants to execute [ array>> 2dup hash@ 0 f
(new-key@) ] with the "keep" combinator. All good so far. "array>>" resolves
to [ 4 slot { array } declare ], which I believe should mean "get the 4th slot
of the object on top of stack and declare to Factor that you know for sure it
is an array". The object on the top of the stack, according to the Inspector,
is a 26-slot hash table that includes such keys as "architecture", "auto-use?",
"bootstrap-syntax", "bootsrapping?", etc.
Now comes the part that baffles me. When I get to executing "slot" (whether I
try to step past it or descend into it), the Walker simply moves me all the way
to the end of the qotation (past "declare") and I see the hash-table and index
from the top of the data stack replaced with a 128-element array that has the
26 key-value pairs from the former hash table spread out through the array
interspersed by tombstone objects; each of these key-value pairs that appear
occupy two adjacent array slots. But I'm completely mystified as to how the
contents of the hash-table got mapped to the array slots they now occupy (there
doesn't seem to be any rhyme or reason). And I have little insight into the
code that accomplished this. Moreover I apparently can't see the 4th slot of
the original object in the Inspector, as it only shows me three slots on the
data stack trace, but organizes them alphabetically when I double-click to open
the Inspector window.
Don't know if any of this was intelligble. But maybe one of you compiler guys
can give me a clue as to how I can understand this. I'm having to reverse
engineer my understanding of all of this, so a break in the logical chain
presents difficulties.
Sorry for the long post.
Regards,
Mike
> Date: Wed, 15 Aug 2012 08:30:10 -0700
> From: doug.cole...@gmail.com
> To: factor-talk@lists.sourceforge.net
> Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
> image?
>
> 1) Factor loads a ~/.factor-rc file every time it starts. You can put
> things there:
>
> USE: too
Re: [Factor-talk] Any way of making sense of what's in the boot image?
In the listener, if you run this code:
IN: scratchpad clear
IN: scratchpad "value" "key" associate
Then step over to [ set-at ] keep
If at this point you just keep stepping "into" things, you should do a deep
dive into all the parts, including the 4 slot { array } declare which
should give you something like {
~tombstone~ ~tombstone~ ~tombstone~ ~tombstone~ } (an array full of
"tombstone" elements which indicate no key or value is present). A
hashtable with deleted elements will have "~empty~". A hashtable with
key/value will have { "key" "value" } at some point in the array. The
array is flattened key/value pairs, so a 4 bucket hashtable will have an 8
element array storing key/value side-by-side starting at the even indices.
I'm not sure what the 26-slot hash table is that you are looking at, so I
put a clear in the code above to make sure your data stack is empty before
walking. It is also possible that you are tracing some code which is
traversing the namespaces (a vector of hashtables containing symbolic
variables used in parts of the code, with names like the ones you mention).
A hashtable has 3 slots (the 0 slot is a numeric value), see:
```
IN: scratchpad \ hashtable "slots" word-prop .
{
T{ slot-spec
{ name "count" }
{ offset 2 }
{ class array-capacity }
{ initial 0 }
}
T{ slot-spec
{ name "deleted" }
{ offset 3 }
{ class array-capacity }
{ initial 0 }
}
T{ slot-spec
{ name "array" }
{ offset 4 }
{ class array }
{ initial { } }
}
}
```
You might also like to try "describe", and poke around at the various word
properties (see "props" below):
```
IN: scratchpad \ hashtable describe
IN: hashtables SYMBOL: hashtable
hashcode 251442479911733628
name "hashtable"
vocabulary"hashtables"
def [ \ hashtable ]
props H{ { "help-parent" "hashtables" } { "slots" ~array~ } { ...
pic-def f
pic-tail-def f
sub-primitive f
```
On Thu, Aug 16, 2012 at 6:01 AM, Michael Clagett wrote:
> Hi --
>
> Okay. I'm going to ask for my first lifeline. :) I'm tracing through
> some arcane stuff indeed. Everything is going along swimmingly. I get to
> the word "new-key@", which at its start wants to execute [ array>> 2dup
> hash@ 0 f (new-key@) ] with the "keep" combinator. All good so far.
> "array>>" resolves to [ 4 slot { array } declare ], which I believe should
> mean "get the 4th slot of the object on top of stack and declare to Factor
> that you know for sure it is an array". The object on the top of the
> stack, according to the Inspector, is a 26-slot hash table that includes
> such keys as "architecture", "auto-use?", "bootstrap-syntax",
> "bootsrapping?", etc.
>
> Now comes the part that baffles me. When I get to executing "slot"
> (whether I try to step past it or descend into it), the Walker simply moves
> me all the way to the end of the qotation (past "declare") and I see the
> hash-table and index from the top of the data stack replaced with a
> 128-element array that has the 26 key-value pairs from the former hash
> table spread out through the array interspersed by tombstone objects; each
> of these key-value pairs that appear occupy two adjacent array slots. But
> I'm completely mystified as to how the contents of the hash-table got
> mapped to the array slots they now occupy (there doesn't seem to be any
> rhyme or reason). And I have little insight into the code that
> accomplished this. Moreover I apparently can't see the 4th slot of the
> original object in the Inspector, as it only shows me three slots on the
> data stack trace, but organizes them alphabetically when I double-click to
> open the Inspector window.
>
> Don't know if any of this was intelligble. But maybe one of you compiler
> guys can give me a clue as to how I can understand this. I'm having to
> reverse engineer my understanding of all of this, so a break in the logical
> chain presents difficulties.
> Sorry for the long post.
>
> Regards,
>
> Mike
>
> > Date: Wed, 15 Aug 2012 08:30:10 -0700
> > From: doug.cole...@gmail.com
>
> > To: factor-talk@lists.sourceforge.net
> > Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
> image?
> >
> > 1) Factor loads a ~/.factor-rc file every time it starts. You can put
> > things there:
> >
> > USE: tools.scaffold
> > scaffold-factor-rc
> >
> > Click it, edit it
Re: [Factor-talk] Any way of making sense of what's in the boot image?
Something just occurred to me about the message below. Could it be that this
array is some sort of underlying layout of the hash table and that the slots of
the target array that hash table contents are mapped to are the underlying
buckets that the hash function maps to? If this were the case, it still
leaves as a mystery why this gets returned from asking for slot # 4 of the hash
table. Maybe I'll go look in the cpp code for the underlying implementation
of hash table and this will all reveal itself.
From: mclag...@hotmail.com
To: factor-talk@lists.sourceforge.net
Date: Thu, 16 Aug 2012 13:01:45 +
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot image?
Hi --
Okay. I'm going to ask for my first lifeline. :) I'm tracing through some
arcane stuff indeed. Everything is going along swimmingly. I get to the word
"new-key@", which at its start wants to execute [ array>> 2dup hash@ 0 f
(new-key@) ] with the "keep" combinator. All good so far. "array>>" resolves
to [ 4 slot { array } declare ], which I believe should mean "get the 4th slot
of the object on top of stack and declare to Factor that you know for sure it
is an array". The object on the top of the stack, according to the Inspector,
is a 26-slot hash table that includes such keys as "architecture", "auto-use?",
"bootstrap-syntax", "bootsrapping?", etc.
Now comes the part that baffles me. When I get to executing "slot" (whether I
try to step past it or descend into it), the Walker simply moves me all the way
to the end of the qotation (past "declare") and I see the hash-table and index
from the top of the data stack replaced with a 128-element array that has the
26 key-value pairs from the former hash table spread out through the array
interspersed by tombstone objects; each of these key-value pairs that appear
occupy two adjacent array slots. But I'm completely mystified as to how the
contents of the hash-table got mapped to the array slots they now occupy (there
doesn't seem to be any rhyme or reason). And I have little insight into the
code that accomplished this. Moreover I apparently can't see the 4th slot of
the original object in the Inspector, as it only shows me three slots on the
data stack trace, but organizes them alphabetically when I double-click to open
the Inspector window.
Don't know if any of this was intelligble. But maybe one of you compiler guys
can give me a clue as to how I can understand this. I'm having to reverse
engineer my understanding of all of this, so a break in the logical chain
presents difficulties.
Sorry for the long post.
Regards,
Mike
> Date: Wed, 15 Aug 2012 08:30:10 -0700
> From: doug.cole...@gmail.com
> To: factor-talk@lists.sourceforge.net
> Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
> image?
>
> 1) Factor loads a ~/.factor-rc file every time it starts. You can put
> things there:
>
> USE: tools.scaffold
> scaffold-factor-rc
>
> Click it, edit it and add:
>
> USING: prettyprint.config namespaces ;
> 16 number-base set-global
>
>
>
> 2) Alternately, there's a boot rc file that gets loaded after bootstrap:
>
> USE: tools.scaffold
> scaffold-factor-boot-rc
>
> Click it, edit it and add:
>
> USING: prettyprint.config namespaces ;
> 16 number-base set-global
>
> To load it without bootstrapping, call 'run-bootstrap-init' and then
> 'save' your image.
>
>
> Doug
>
>
> On Wed, Aug 15, 2012 at 8:22 AM, Michael Clagett wrote:
> > Thanks. I knew it had to be something like that. And if I want it to be
> > the default every time I load the Listener, I'm sure there must be a way to
> > set that up?
> >
> > Sent from my iPhone
> >
> > On Aug 15, 2012, at 11:01 AM, "John Benediktsson" wrote:
> >
> > If you want all numbers to print in hex, the easiest way is:
> >
> > ```
> > IN: scratchpad 16 number-base set-global
> > ```
> >
> >
> > On Wed, Aug 15, 2012 at 4:04 AM, Michael Clagett
> > wrote:
> >>
> >> Quick question. Any way of having the data and retain stack panes of the
> >> Walker display values in hex?
> >>
> >> > Date: Mon, 13 Aug 2012 12:21:52 -0400
> >> > From: arc...@gmail.com
> >> > To: factor-talk@lists.sourceforge.net
> >> > Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
> >> > image?
> >> >
> >> > On Mon, Aug 13, 2012 at 11:52 AM, Michael Clagett
> >> > wrote:
> >> > > Here'
Re: [Factor-talk] Any way of making sense of what's in the boot image?
Hi -- Okay. I'm going to ask for my first lifeline. :) I'm tracing through
some arcane stuff indeed. Everything is going along swimmingly. I get to the
word "new-key@", which at its start wants to execute [ array>> 2dup hash@ 0 f
(new-key@) ] with the "keep" combinator. All good so far. "array>>" resolves
to [ 4 slot { array } declare ], which I believe should mean "get the 4th slot
of the object on top of stack and declare to Factor that you know for sure it
is an array". The object on the top of the stack, according to the Inspector,
is a 26-slot hash table that includes such keys as "architecture", "auto-use?",
"bootstrap-syntax", "bootsrapping?", etc. Now comes the part that baffles me.
When I get to executing "slot" (whether I try to step past it or descend into
it), the Walker simply moves me all the way to the end of the qotation (past
"declare") and I see the hash-table and index from the top of the data stack
replaced with a 128-element array that has the 26 key-value pairs from the
former hash table spread out through the array interspersed by tombstone
objects; each of these key-value pairs that appear occupy two adjacent array
slots. But I'm completely mystified as to how the contents of the hash-table
got mapped to the array slots they now occupy (there doesn't seem to be any
rhyme or reason). And I have little insight into the code that accomplished
this. Moreover I apparently can't see the 4th slot of the original object in
the Inspector, as it only shows me three slots on the data stack trace, but
organizes them alphabetically when I double-click to open the Inspector window.
Don't know if any of this was intelligble. But maybe one of you compiler guys
can give me a clue as to how I can understand this. I'm having to reverse
engineer my understanding of all of this, so a break in the logical chain
presents difficulties.Sorry for the long post. Regards, Mike
> Date: Wed, 15 Aug 2012 08:30:10 -0700
> From: doug.cole...@gmail.com
> To: factor-talk@lists.sourceforge.net
> Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
> image?
>
> 1) Factor loads a ~/.factor-rc file every time it starts. You can put
> things there:
>
> USE: tools.scaffold
> scaffold-factor-rc
>
> Click it, edit it and add:
>
> USING: prettyprint.config namespaces ;
> 16 number-base set-global
>
>
>
> 2) Alternately, there's a boot rc file that gets loaded after bootstrap:
>
> USE: tools.scaffold
> scaffold-factor-boot-rc
>
> Click it, edit it and add:
>
> USING: prettyprint.config namespaces ;
> 16 number-base set-global
>
> To load it without bootstrapping, call 'run-bootstrap-init' and then
> 'save' your image.
>
>
> Doug
>
>
> On Wed, Aug 15, 2012 at 8:22 AM, Michael Clagett wrote:
> > Thanks. I knew it had to be something like that. And if I want it to be
> > the default every time I load the Listener, I'm sure there must be a way to
> > set that up?
> >
> > Sent from my iPhone
> >
> > On Aug 15, 2012, at 11:01 AM, "John Benediktsson" wrote:
> >
> > If you want all numbers to print in hex, the easiest way is:
> >
> > ```
> > IN: scratchpad 16 number-base set-global
> > ```
> >
> >
> > On Wed, Aug 15, 2012 at 4:04 AM, Michael Clagett
> > wrote:
> >>
> >> Quick question. Any way of having the data and retain stack panes of the
> >> Walker display values in hex?
> >>
> >> > Date: Mon, 13 Aug 2012 12:21:52 -0400
> >> > From: arc...@gmail.com
> >> > To: factor-talk@lists.sourceforge.net
> >> > Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
> >> > image?
> >> >
> >> > On Mon, Aug 13, 2012 at 11:52 AM, Michael Clagett
> >> > wrote:
> >> > > Here's an obscure question that is of interest to me in my current
> >> > > quest,
> >> > > but probably not to anyone else. So if there is a better forum for me
> >> > > to
> >> > > ask such things, I would love to be instructed; until I hear
> >> > > otherwise,
> >> > > however, I will continue to use this list.
> >> > >
> >> > > Is there any place where I can penetrate the meaning of the following
> >> > > constants:
> >> > >
> >> > > CONSTANT: rt-dlsym 0
> >> > > CONSTANT: rt-entry-point 1
> >> > > CONSTANT: rt-entry-
Re: [Factor-talk] Any way of making sense of what's in the boot image?
Beautiful. Thanks. Sent from my iPhone On Aug 15, 2012, at 11:30 AM, "Doug Coleman" wrote: > 1) Factor loads a ~/.factor-rc file every time it starts. You can put > things there: > > USE: tools.scaffold > scaffold-factor-rc > > Click it, edit it and add: > > USING: prettyprint.config namespaces ; > 16 number-base set-global > > > > 2) Alternately, there's a boot rc file that gets loaded after bootstrap: > > USE: tools.scaffold > scaffold-factor-boot-rc > > Click it, edit it and add: > > USING: prettyprint.config namespaces ; > 16 number-base set-global > > To load it without bootstrapping, call 'run-bootstrap-init' and then > 'save' your image. > > > Doug > > > On Wed, Aug 15, 2012 at 8:22 AM, Michael Clagett wrote: >> Thanks. I knew it had to be something like that. And if I want it to be >> the default every time I load the Listener, I'm sure there must be a way to >> set that up? >> >> Sent from my iPhone >> >> On Aug 15, 2012, at 11:01 AM, "John Benediktsson" wrote: >> >> If you want all numbers to print in hex, the easiest way is: >> >> ``` >> IN: scratchpad 16 number-base set-global >> ``` >> >> >> On Wed, Aug 15, 2012 at 4:04 AM, Michael Clagett >> wrote: >>> >>> Quick question. Any way of having the data and retain stack panes of the >>> Walker display values in hex? >>> >>>> Date: Mon, 13 Aug 2012 12:21:52 -0400 >>>> From: arc...@gmail.com >>>> To: factor-talk@lists.sourceforge.net >>>> Subject: Re: [Factor-talk] Any way of making sense of what's in the boot >>>> image? >>>> >>>> On Mon, Aug 13, 2012 at 11:52 AM, Michael Clagett >>>> wrote: >>>>> Here's an obscure question that is of interest to me in my current >>>>> quest, >>>>> but probably not to anyone else. So if there is a better forum for me >>>>> to >>>>> ask such things, I would love to be instructed; until I hear >>>>> otherwise, >>>>> however, I will continue to use this list. >>>>> >>>>> Is there any place where I can penetrate the meaning of the following >>>>> constants: >>>>> >>>>> CONSTANT: rt-dlsym 0 >>>>> CONSTANT: rt-entry-point 1 >>>>> CONSTANT: rt-entry-point-pic 2 >>>>> CONSTANT: rt-entry-point-pic-tail 3 >>>>> CONSTANT: rt-here 4 >>>>> CONSTANT: rt-this 5 >>>>> CONSTANT: rt-literal 6 >>>>> CONSTANT: rt-untagged 7 >>>>> CONSTANT: rt-megamorphic-cache-hits 8 >>>>> CONSTANT: rt-vm 9 >>>>> CONSTANT: rt-cards-offset 10 >>>>> CONSTANT: rt-decks-offset 11 >>>>> CONSTANT: rt-exception-handler 12 >>>>> CONSTANT: rt-dlsym-toc 13 >>>>> CONSTANT: rt-inline-cache-miss 14 >>>>> CONSTANT: rt-safepoint 15 >>>>> >>>>> So far I've only encountered rt-here and I've only seen it encoded >>>>> into a >>>>> relocation entry and not really used anywhere yet. But this strikes me >>>>> as >>>>> the kind of thing it would be useful to know as I am slogging through >>>>> this >>>>> stuff. >>>>> >>>>> Not a hugely pressing question, as I'm sure I'll muddle through it. >>>>> But if >>>>> anyone has a moment to illuminate, it would be nice. >>>> >>>> Those are relocation record types. When the compiler generates code >>>> for a word, it also needs to generate relocation entries every time it >>>> references another word in a jump or call statement, much like a >>>> native C compiler needs to do for symbols in other modules. >>>> The VM uses these relocation entries to update the operands of jump >>>> and call instructions when code is written to the code heap, when the >>>> code heap is compacted, or if code is moved in memory for any reason. >>>> The different rt-* constants are used to describe what kind of object >>>> a relocation refers to, such as a foreign function in a DLL (dlsym), a >>>> word entry point (entry-point-*), the current address (here), etc. >>>> >>>> -Joe >>>> >>>> >>>> --
Re: [Factor-talk] Any way of making sense of what's in the boot image?
1) Factor loads a ~/.factor-rc file every time it starts. You can put things there: USE: tools.scaffold scaffold-factor-rc Click it, edit it and add: USING: prettyprint.config namespaces ; 16 number-base set-global 2) Alternately, there's a boot rc file that gets loaded after bootstrap: USE: tools.scaffold scaffold-factor-boot-rc Click it, edit it and add: USING: prettyprint.config namespaces ; 16 number-base set-global To load it without bootstrapping, call 'run-bootstrap-init' and then 'save' your image. Doug On Wed, Aug 15, 2012 at 8:22 AM, Michael Clagett wrote: > Thanks. I knew it had to be something like that. And if I want it to be > the default every time I load the Listener, I'm sure there must be a way to > set that up? > > Sent from my iPhone > > On Aug 15, 2012, at 11:01 AM, "John Benediktsson" wrote: > > If you want all numbers to print in hex, the easiest way is: > > ``` > IN: scratchpad 16 number-base set-global > ``` > > > On Wed, Aug 15, 2012 at 4:04 AM, Michael Clagett > wrote: >> >> Quick question. Any way of having the data and retain stack panes of the >> Walker display values in hex? >> >> > Date: Mon, 13 Aug 2012 12:21:52 -0400 >> > From: arc...@gmail.com >> > To: factor-talk@lists.sourceforge.net >> > Subject: Re: [Factor-talk] Any way of making sense of what's in the boot >> > image? >> > >> > On Mon, Aug 13, 2012 at 11:52 AM, Michael Clagett >> > wrote: >> > > Here's an obscure question that is of interest to me in my current >> > > quest, >> > > but probably not to anyone else. So if there is a better forum for me >> > > to >> > > ask such things, I would love to be instructed; until I hear >> > > otherwise, >> > > however, I will continue to use this list. >> > > >> > > Is there any place where I can penetrate the meaning of the following >> > > constants: >> > > >> > > CONSTANT: rt-dlsym 0 >> > > CONSTANT: rt-entry-point 1 >> > > CONSTANT: rt-entry-point-pic 2 >> > > CONSTANT: rt-entry-point-pic-tail 3 >> > > CONSTANT: rt-here 4 >> > > CONSTANT: rt-this 5 >> > > CONSTANT: rt-literal 6 >> > > CONSTANT: rt-untagged 7 >> > > CONSTANT: rt-megamorphic-cache-hits 8 >> > > CONSTANT: rt-vm 9 >> > > CONSTANT: rt-cards-offset 10 >> > > CONSTANT: rt-decks-offset 11 >> > > CONSTANT: rt-exception-handler 12 >> > > CONSTANT: rt-dlsym-toc 13 >> > > CONSTANT: rt-inline-cache-miss 14 >> > > CONSTANT: rt-safepoint 15 >> > > >> > > So far I've only encountered rt-here and I've only seen it encoded >> > > into a >> > > relocation entry and not really used anywhere yet. But this strikes me >> > > as >> > > the kind of thing it would be useful to know as I am slogging through >> > > this >> > > stuff. >> > > >> > > Not a hugely pressing question, as I'm sure I'll muddle through it. >> > > But if >> > > anyone has a moment to illuminate, it would be nice. >> > >> > Those are relocation record types. When the compiler generates code >> > for a word, it also needs to generate relocation entries every time it >> > references another word in a jump or call statement, much like a >> > native C compiler needs to do for symbols in other modules. >> > The VM uses these relocation entries to update the operands of jump >> > and call instructions when code is written to the code heap, when the >> > code heap is compacted, or if code is moved in memory for any reason. >> > The different rt-* constants are used to describe what kind of object >> > a relocation refers to, such as a foreign function in a DLL (dlsym), a >> > word entry point (entry-point-*), the current address (here), etc. >> > >> > -Joe >> > >> > >> > -- >> > Live Security Virtual Conference >> > Exclusive live event will cover all the ways today's security and >> > threat landscape has changed and how IT managers can respond. >> > Discussions >> > will include endpoint security, mobile security and the latest in >> > malware >> > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> > ___ >&g
Re: [Factor-talk] Any way of making sense of what's in the boot image?
Thanks. I knew it had to be something like that. And if I want it to be the default every time I load the Listener, I'm sure there must be a way to set that up? Sent from my iPhone On Aug 15, 2012, at 11:01 AM, "John Benediktsson" wrote: > If you want all numbers to print in hex, the easiest way is: > > ``` > IN: scratchpad 16 number-base set-global > ``` > > > On Wed, Aug 15, 2012 at 4:04 AM, Michael Clagett wrote: > Quick question. Any way of having the data and retain stack panes of the > Walker display values in hex? > > > Date: Mon, 13 Aug 2012 12:21:52 -0400 > > From: arc...@gmail.com > > To: factor-talk@lists.sourceforge.net > > Subject: Re: [Factor-talk] Any way of making sense of what's in the boot > > image? > > > > On Mon, Aug 13, 2012 at 11:52 AM, Michael Clagett > > wrote: > > > Here's an obscure question that is of interest to me in my current quest, > > > but probably not to anyone else. So if there is a better forum for me to > > > ask such things, I would love to be instructed; until I hear otherwise, > > > however, I will continue to use this list. > > > > > > Is there any place where I can penetrate the meaning of the following > > > constants: > > > > > > CONSTANT: rt-dlsym 0 > > > CONSTANT: rt-entry-point 1 > > > CONSTANT: rt-entry-point-pic 2 > > > CONSTANT: rt-entry-point-pic-tail 3 > > > CONSTANT: rt-here 4 > > > CONSTANT: rt-this 5 > > > CONSTANT: rt-literal 6 > > > CONSTANT: rt-untagged 7 > > > CONSTANT: rt-megamorphic-cache-hits 8 > > > CONSTANT: rt-vm 9 > > > CONSTANT: rt-cards-offset 10 > > > CONSTANT: rt-decks-offset 11 > > > CONSTANT: rt-exception-handler 12 > > > CONSTANT: rt-dlsym-toc 13 > > > CONSTANT: rt-inline-cache-miss 14 > > > CONSTANT: rt-safepoint 15 > > > > > > So far I've only encountered rt-here and I've only seen it encoded into a > > > relocation entry and not really used anywhere yet. But this strikes me as > > > the kind of thing it would be useful to know as I am slogging through this > > > stuff. > > > > > > Not a hugely pressing question, as I'm sure I'll muddle through it. But if > > > anyone has a moment to illuminate, it would be nice. > > > > Those are relocation record types. When the compiler generates code > > for a word, it also needs to generate relocation entries every time it > > references another word in a jump or call statement, much like a > > native C compiler needs to do for symbols in other modules. > > The VM uses these relocation entries to update the operands of jump > > and call instructions when code is written to the code heap, when the > > code heap is compacted, or if code is moved in memory for any reason. > > The different rt-* constants are used to describe what kind of object > > a relocation refers to, such as a foreign function in a DLL (dlsym), a > > word entry point (entry-point-*), the current address (here), etc. > > > > -Joe > > > > -- > > Live Security Virtual Conference > > Exclusive live event will cover all the ways today's security and > > threat landscape has changed and how IT managers can respond. Discussions > > will include endpoint security, mobile security and the latest in malware > > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > ___ > > Factor-talk mailing list > > Factor-talk@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/factor-talk > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > Factor-talk mailing list > Factor-talk@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/factor-talk > > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint sec
Re: [Factor-talk] Any way of making sense of what's in the boot image?
If you want all numbers to print in hex, the easiest way is: ``` IN: scratchpad 16 number-base set-global ``` On Wed, Aug 15, 2012 at 4:04 AM, Michael Clagett wrote: > Quick question. Any way of having the data and retain stack panes of > the Walker display values in hex? > > > Date: Mon, 13 Aug 2012 12:21:52 -0400 > > From: arc...@gmail.com > > To: factor-talk@lists.sourceforge.net > > Subject: Re: [Factor-talk] Any way of making sense of what's in the boot > image? > > > > On Mon, Aug 13, 2012 at 11:52 AM, Michael Clagett > wrote: > > > Here's an obscure question that is of interest to me in my current > quest, > > > but probably not to anyone else. So if there is a better forum for me > to > > > ask such things, I would love to be instructed; until I hear otherwise, > > > however, I will continue to use this list. > > > > > > Is there any place where I can penetrate the meaning of the following > > > constants: > > > > > > CONSTANT: rt-dlsym 0 > > > CONSTANT: rt-entry-point 1 > > > CONSTANT: rt-entry-point-pic 2 > > > CONSTANT: rt-entry-point-pic-tail 3 > > > CONSTANT: rt-here 4 > > > CONSTANT: rt-this 5 > > > CONSTANT: rt-literal 6 > > > CONSTANT: rt-untagged 7 > > > CONSTANT: rt-megamorphic-cache-hits 8 > > > CONSTANT: rt-vm 9 > > > CONSTANT: rt-cards-offset 10 > > > CONSTANT: rt-decks-offset 11 > > > CONSTANT: rt-exception-handler 12 > > > CONSTANT: rt-dlsym-toc 13 > > > CONSTANT: rt-inline-cache-miss 14 > > > CONSTANT: rt-safepoint 15 > > > > > > So far I've only encountered rt-here and I've only seen it encoded > into a > > > relocation entry and not really used anywhere yet. But this strikes me > as > > > the kind of thing it would be useful to know as I am slogging through > this > > > stuff. > > > > > > Not a hugely pressing question, as I'm sure I'll muddle through it. > But if > > > anyone has a moment to illuminate, it would be nice. > > > > Those are relocation record types. When the compiler generates code > > for a word, it also needs to generate relocation entries every time it > > references another word in a jump or call statement, much like a > > native C compiler needs to do for symbols in other modules. > > The VM uses these relocation entries to update the operands of jump > > and call instructions when code is written to the code heap, when the > > code heap is compacted, or if code is moved in memory for any reason. > > The different rt-* constants are used to describe what kind of object > > a relocation refers to, such as a foreign function in a DLL (dlsym), a > > word entry point (entry-point-*), the current address (here), etc. > > > > -Joe > > > > > -- > > Live Security Virtual Conference > > Exclusive live event will cover all the ways today's security and > > threat landscape has changed and how IT managers can respond. > Discussions > > will include endpoint security, mobile security and the latest in > malware > > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > ___ > > Factor-talk mailing list > > Factor-talk@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/factor-talk > > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > Factor-talk mailing list > Factor-talk@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/factor-talk > > -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Any way of making sense of what's in the boot image?
Quick question. Any way of having the data and retain stack panes of the Walker display values in hex? > Date: Mon, 13 Aug 2012 12:21:52 -0400 > From: arc...@gmail.com > To: factor-talk@lists.sourceforge.net > Subject: Re: [Factor-talk] Any way of making sense of what's in the boot > image? > > On Mon, Aug 13, 2012 at 11:52 AM, Michael Clagett > wrote: > > Here's an obscure question that is of interest to me in my current quest, > > but probably not to anyone else. So if there is a better forum for me to > > ask such things, I would love to be instructed; until I hear otherwise, > > however, I will continue to use this list. > > > > Is there any place where I can penetrate the meaning of the following > > constants: > > > > CONSTANT: rt-dlsym 0 > > CONSTANT: rt-entry-point 1 > > CONSTANT: rt-entry-point-pic 2 > > CONSTANT: rt-entry-point-pic-tail 3 > > CONSTANT: rt-here 4 > > CONSTANT: rt-this 5 > > CONSTANT: rt-literal 6 > > CONSTANT: rt-untagged 7 > > CONSTANT: rt-megamorphic-cache-hits 8 > > CONSTANT: rt-vm 9 > > CONSTANT: rt-cards-offset 10 > > CONSTANT: rt-decks-offset 11 > > CONSTANT: rt-exception-handler 12 > > CONSTANT: rt-dlsym-toc 13 > > CONSTANT: rt-inline-cache-miss 14 > > CONSTANT: rt-safepoint 15 > > > > So far I've only encountered rt-here and I've only seen it encoded into a > > relocation entry and not really used anywhere yet. But this strikes me as > > the kind of thing it would be useful to know as I am slogging through this > > stuff. > > > > Not a hugely pressing question, as I'm sure I'll muddle through it. But if > > anyone has a moment to illuminate, it would be nice. > > Those are relocation record types. When the compiler generates code > for a word, it also needs to generate relocation entries every time it > references another word in a jump or call statement, much like a > native C compiler needs to do for symbols in other modules. > The VM uses these relocation entries to update the operands of jump > and call instructions when code is written to the code heap, when the > code heap is compacted, or if code is moved in memory for any reason. > The different rt-* constants are used to describe what kind of object > a relocation refers to, such as a foreign function in a DLL (dlsym), a > word entry point (entry-point-*), the current address (here), etc. > > -Joe > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > Factor-talk mailing list > Factor-talk@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/factor-talk -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Any way of making sense of what's in the boot image?
Roger, that. I will definitely do it. In fact, I think you will be pleasantly surprised. From: mrj...@gmail.com Date: Tue, 14 Aug 2012 17:35:39 -0700 To: factor-talk@lists.sourceforge.net Subject: Re: [Factor-talk] Any way of making sense of what's in the boot image? Any documentation that you write as part of your investigation would be welcome contributions. On Tue, Aug 14, 2012 at 5:27 PM, Michael Clagett wrote: One constructive criticism type comment, if you'll permit me. While what I say directly below is absolutely true, it's true on a micro level. At the broader level, the heavy use of (sometimes lengthy) quotations to feed workhorse words like "define-sub-primitive" make understanding what's going on quite difficult. Although I realize the bootstrapping mechanism is not a general area of interest to many, I think something on the order of about 25 well-placed comments prefacing some of the more extensive quotations would help improve readability tremendously, just in case someone needs to understand the internals of this mechanism. Just a thought, offered in a spirit of complete good will and overall general awe at the care and discipline that has gone into this work. From: mclag...@hotmail.com To: factor-talk@lists.sourceforge.net Subject: RE: [Factor-talk] Any way of making sense of what's in the boot image? Date: Tue, 14 Aug 2012 05:28:45 + Been looking at some of the x86 assembler code. Damn! All I can say is that I wish to hell I had had Factor when I wrote my own. Quite a bit different approach, but the clarity and succinctness is tantalizing. From: mclag...@hotmail.com To: factor-talk@lists.sourceforge.net Date: Mon, 13 Aug 2012 16:46:38 +0000 Subject: Re: [Factor-talk] Any way of making sense of what's in the boot image? Thank you, Joe, for the quick response. It was actually the information in the "such as" clause of your last sentence that I was looking for. I don't mean for you to take the time out to document the meaning of these different constants, but if it is documented somewhere other than in the creators' heads, I would love to be directed to it. Not a big deal, because I'm sure that when I get to seeing them used in the boot-image initialization code, all will become clear. Still, it might help me better understand what's being done at the make-image level to know. > Date: Mon, 13 Aug 2012 12:21:52 -0400 > From: arc...@gmail.com > To: factor-talk@lists.sourceforge.net > Subject: Re: [Factor-talk] Any way of making sense of what's in the boot > image? > > On Mon, Aug 13, 2012 at 11:52 AM, Michael Clagett > wrote: > > Here's an obscure question that is of interest to me in my current quest, > > but probably not to anyone else. So if there is a better forum for me to > > ask such things, I would love to be instructed; until I hear otherwise, > > however, I will continue to use this list. > > > > Is there any place where I can penetrate the meaning of the following > > constants: > > > > CONSTANT: rt-dlsym 0 > > CONSTANT: rt-entry-point 1 > > CONSTANT: rt-entry-point-pic 2 > > CONSTANT: rt-entry-point-pic-tail 3 > > CONSTANT: rt-here 4 > > CONSTANT: rt-this 5 > > CONSTANT: rt-literal 6 > > CONSTANT: rt-untagged 7 > > CONSTANT: rt-megamorphic-cache-hits 8 > > CONSTANT: rt-vm 9 > > CONSTANT: rt-cards-offset 10 > > CONSTANT: rt-decks-offset 11 > > CONSTANT: rt-exception-handler 12 > > CONSTANT: rt-dlsym-toc 13 > > CONSTANT: rt-inline-cache-miss 14 > > CONSTANT: rt-safepoint 15 > > > > So far I've only encountered rt-here and I've only seen it encoded into a > > relocation entry and not really used anywhere yet. But this strikes me as > > the kind of thing it would be useful to know as I am slogging through this > > stuff. > > > > Not a hugely pressing question, as I'm sure I'll muddle through it. But if > > anyone has a moment to illuminate, it would be nice. > > Those are relocation record types. When the compiler generates code > for a word, it also needs to generate relocation entries every time it > references another word in a jump or call statement, much like a > native C compiler needs to do for symbols in other modules. > The VM uses these relocation entries to update the operands of jump > and call instructions when code is written to the code heap, when the > code heap is compacted, or if code is moved in memory for any reason. > The different rt-* constants are used to describe what kind of object > a relocation refers to, such as a foreign function in a DLL (dlsym), a > word entry point (entry-point-*), t
Re: [Factor-talk] Any way of making sense of what's in the boot image?
Any documentation that you write as part of your investigation would be welcome contributions. On Tue, Aug 14, 2012 at 5:27 PM, Michael Clagett wrote: > One constructive criticism type comment, if you'll permit me. While > what I say directly below is absolutely true, it's true on a micro level. > At the broader level, the heavy use of (sometimes lengthy) quotations to > feed workhorse words like "define-sub-primitive" make understanding what's > going on quite difficult. Although I realize the bootstrapping mechanism > is not a general area of interest to many, I think something on the order > of about 25 well-placed comments prefacing some of the more extensive > quotations would help improve readability tremendously, just in case > someone needs to understand the internals of this mechanism. > > Just a thought, offered in a spirit of complete good will and overall > general awe at the care and discipline that has gone into this work. > > -- > From: mclag...@hotmail.com > To: factor-talk@lists.sourceforge.net > Subject: RE: [Factor-talk] Any way of making sense of what's in the boot > image? > Date: Tue, 14 Aug 2012 05:28:45 + > > > Been looking at some of the x86 assembler code. Damn! All I can say is > that I wish to hell I had had Factor when I wrote my own. Quite a bit > different approach, but the clarity and succinctness is tantalizing. > > -- > From: mclag...@hotmail.com > To: factor-talk@lists.sourceforge.net > Date: Mon, 13 Aug 2012 16:46:38 + > Subject: Re: [Factor-talk] Any way of making sense of what's in the boot > image? > > Thank you, Joe, for the quick response. It was actually the information > in the "such as" clause of your last sentence that I was looking for. I > don't mean for you to take the time out to document the meaning of these > different constants, but if it is documented somewhere other than in the > creators' heads, I would love to be directed to it. Not a big deal, > because I'm sure that when I get to seeing them used in the boot-image > initialization code, all will become clear. Still, it might help me better > understand what's being done at the make-image level to know. > > Date: Mon, 13 Aug 2012 12:21:52 -0400 > > From: arc...@gmail.com > > To: factor-talk@lists.sourceforge.net > > Subject: Re: [Factor-talk] Any way of making sense of what's in the boot > image? > > > > On Mon, Aug 13, 2012 at 11:52 AM, Michael Clagett > wrote: > > > Here's an obscure question that is of interest to me in my current > quest, > > > but probably not to anyone else. So if there is a better forum for me > to > > > ask such things, I would love to be instructed; until I hear otherwise, > > > however, I will continue to use this list. > > > > > > Is there any place where I can penetrate the meaning of the following > > > constants: > > > > > > CONSTANT: rt-dlsym 0 > > > CONSTANT: rt-entry-point 1 > > > CONSTANT: rt-entry-point-pic 2 > > > CONSTANT: rt-entry-point-pic-tail 3 > > > CONSTANT: rt-here 4 > > > CONSTANT: rt-this 5 > > > CONSTANT: rt-literal 6 > > > CONSTANT: rt-untagged 7 > > > CONSTANT: rt-megamorphic-cache-hits 8 > > > CONSTANT: rt-vm 9 > > > CONSTANT: rt-cards-offset 10 > > > CONSTANT: rt-decks-offset 11 > > > CONSTANT: rt-exception-handler 12 > > > CONSTANT: rt-dlsym-toc 13 > > > CONSTANT: rt-inline-cache-miss 14 > > > CONSTANT: rt-safepoint 15 > > > > > > So far I've only encountered rt-here and I've only seen it encoded > into a > > > relocation entry and not really used anywhere yet. But this strikes me > as > > > the kind of thing it would be useful to know as I am slogging through > this > > > stuff. > > > > > > Not a hugely pressing question, as I'm sure I'll muddle through it. > But if > > > anyone has a moment to illuminate, it would be nice. > > > > Those are relocation record types. When the compiler generates code > > for a word, it also needs to generate relocation entries every time it > > references another word in a jump or call statement, much like a > > native C compiler needs to do for symbols in other modules. > > The VM uses these relocation entries to update the operands of jump > > and call instructions when code is written to the code heap, when the > > code heap is compacted, or if code is moved in memory for any reason. > > The different rt-* constants are used
Re: [Factor-talk] Any way of making sense of what's in the boot image?
One constructive criticism type comment, if you'll permit me. While what I say directly below is absolutely true, it's true on a micro level. At the broader level, the heavy use of (sometimes lengthy) quotations to feed workhorse words like "define-sub-primitive" make understanding what's going on quite difficult. Although I realize the bootstrapping mechanism is not a general area of interest to many, I think something on the order of about 25 well-placed comments prefacing some of the more extensive quotations would help improve readability tremendously, just in case someone needs to understand the internals of this mechanism. Just a thought, offered in a spirit of complete good will and overall general awe at the care and discipline that has gone into this work. From: mclag...@hotmail.com To: factor-talk@lists.sourceforge.net Subject: RE: [Factor-talk] Any way of making sense of what's in the boot image? Date: Tue, 14 Aug 2012 05:28:45 + Been looking at some of the x86 assembler code. Damn! All I can say is that I wish to hell I had had Factor when I wrote my own. Quite a bit different approach, but the clarity and succinctness is tantalizing. From: mclag...@hotmail.com To: factor-talk@lists.sourceforge.net Date: Mon, 13 Aug 2012 16:46:38 +0000 Subject: Re: [Factor-talk] Any way of making sense of what's in the boot image? Thank you, Joe, for the quick response. It was actually the information in the "such as" clause of your last sentence that I was looking for. I don't mean for you to take the time out to document the meaning of these different constants, but if it is documented somewhere other than in the creators' heads, I would love to be directed to it. Not a big deal, because I'm sure that when I get to seeing them used in the boot-image initialization code, all will become clear. Still, it might help me better understand what's being done at the make-image level to know. > Date: Mon, 13 Aug 2012 12:21:52 -0400 > From: arc...@gmail.com > To: factor-talk@lists.sourceforge.net > Subject: Re: [Factor-talk] Any way of making sense of what's in the boot > image? > > On Mon, Aug 13, 2012 at 11:52 AM, Michael Clagett > wrote: > > Here's an obscure question that is of interest to me in my current quest, > > but probably not to anyone else. So if there is a better forum for me to > > ask such things, I would love to be instructed; until I hear otherwise, > > however, I will continue to use this list. > > > > Is there any place where I can penetrate the meaning of the following > > constants: > > > > CONSTANT: rt-dlsym 0 > > CONSTANT: rt-entry-point 1 > > CONSTANT: rt-entry-point-pic 2 > > CONSTANT: rt-entry-point-pic-tail 3 > > CONSTANT: rt-here 4 > > CONSTANT: rt-this 5 > > CONSTANT: rt-literal 6 > > CONSTANT: rt-untagged 7 > > CONSTANT: rt-megamorphic-cache-hits 8 > > CONSTANT: rt-vm 9 > > CONSTANT: rt-cards-offset 10 > > CONSTANT: rt-decks-offset 11 > > CONSTANT: rt-exception-handler 12 > > CONSTANT: rt-dlsym-toc 13 > > CONSTANT: rt-inline-cache-miss 14 > > CONSTANT: rt-safepoint 15 > > > > So far I've only encountered rt-here and I've only seen it encoded into a > > relocation entry and not really used anywhere yet. But this strikes me as > > the kind of thing it would be useful to know as I am slogging through this > > stuff. > > > > Not a hugely pressing question, as I'm sure I'll muddle through it. But if > > anyone has a moment to illuminate, it would be nice. > > Those are relocation record types. When the compiler generates code > for a word, it also needs to generate relocation entries every time it > references another word in a jump or call statement, much like a > native C compiler needs to do for symbols in other modules. > The VM uses these relocation entries to update the operands of jump > and call instructions when code is written to the code heap, when the > code heap is compacted, or if code is moved in memory for any reason. > The different rt-* constants are used to describe what kind of object > a relocation refers to, such as a foreign function in a DLL (dlsym), a > word entry point (entry-point-*), the current address (here), etc. > > -Joe > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/501222
Re: [Factor-talk] Any way of making sense of what's in the boot image?
Been looking at some of the x86 assembler code. Damn! All I can say is that I wish to hell I had had Factor when I wrote my own. Quite a bit different approach, but the clarity and succinctness is tantalizing. From: mclag...@hotmail.com To: factor-talk@lists.sourceforge.net Date: Mon, 13 Aug 2012 16:46:38 + Subject: Re: [Factor-talk] Any way of making sense of what's in the boot image? Thank you, Joe, for the quick response. It was actually the information in the "such as" clause of your last sentence that I was looking for. I don't mean for you to take the time out to document the meaning of these different constants, but if it is documented somewhere other than in the creators' heads, I would love to be directed to it. Not a big deal, because I'm sure that when I get to seeing them used in the boot-image initialization code, all will become clear. Still, it might help me better understand what's being done at the make-image level to know. > Date: Mon, 13 Aug 2012 12:21:52 -0400 > From: arc...@gmail.com > To: factor-talk@lists.sourceforge.net > Subject: Re: [Factor-talk] Any way of making sense of what's in the boot > image? > > On Mon, Aug 13, 2012 at 11:52 AM, Michael Clagett > wrote: > > Here's an obscure question that is of interest to me in my current quest, > > but probably not to anyone else. So if there is a better forum for me to > > ask such things, I would love to be instructed; until I hear otherwise, > > however, I will continue to use this list. > > > > Is there any place where I can penetrate the meaning of the following > > constants: > > > > CONSTANT: rt-dlsym 0 > > CONSTANT: rt-entry-point 1 > > CONSTANT: rt-entry-point-pic 2 > > CONSTANT: rt-entry-point-pic-tail 3 > > CONSTANT: rt-here 4 > > CONSTANT: rt-this 5 > > CONSTANT: rt-literal 6 > > CONSTANT: rt-untagged 7 > > CONSTANT: rt-megamorphic-cache-hits 8 > > CONSTANT: rt-vm 9 > > CONSTANT: rt-cards-offset 10 > > CONSTANT: rt-decks-offset 11 > > CONSTANT: rt-exception-handler 12 > > CONSTANT: rt-dlsym-toc 13 > > CONSTANT: rt-inline-cache-miss 14 > > CONSTANT: rt-safepoint 15 > > > > So far I've only encountered rt-here and I've only seen it encoded into a > > relocation entry and not really used anywhere yet. But this strikes me as > > the kind of thing it would be useful to know as I am slogging through this > > stuff. > > > > Not a hugely pressing question, as I'm sure I'll muddle through it. But if > > anyone has a moment to illuminate, it would be nice. > > Those are relocation record types. When the compiler generates code > for a word, it also needs to generate relocation entries every time it > references another word in a jump or call statement, much like a > native C compiler needs to do for symbols in other modules. > The VM uses these relocation entries to update the operands of jump > and call instructions when code is written to the code heap, when the > code heap is compacted, or if code is moved in memory for any reason. > The different rt-* constants are used to describe what kind of object > a relocation refers to, such as a foreign function in a DLL (dlsym), a > word entry point (entry-point-*), the current address (here), etc. > > -Joe > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > Factor-talk mailing list > Factor-talk@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/factor-talk -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk -- Live Security Virtual Conference Exclusive live event will cover all the ways today's secu
Re: [Factor-talk] Any way of making sense of what's in the boot image?
(So you had better be nice to me; I don't mess around.) > Date: Mon, 13 Aug 2012 09:50:04 -0700 > From: doug.cole...@gmail.com > To: factor-talk@lists.sourceforge.net > Subject: Re: [Factor-talk] Any way of making sense of what's in the boot > image? > > Is this you? > > http://www.clarkprosecutor.org/html/death/US/clagett651.htm > > On Mon, Aug 13, 2012 at 9:46 AM, Michael Clagett wrote: > > Thank you, Joe, for the quick response. It was actually the information in > > the "such as" clause of your last sentence that I was looking for. I don't > > mean for you to take the time out to document the meaning of these different > > constants, but if it is documented somewhere other than in the creators' > > heads, I would love to be directed to it. Not a big deal, because I'm sure > > that when I get to seeing them used in the boot-image initialization code, > > all will become clear. Still, it might help me better understand what's > > being done at the make-image level to know. > >> Date: Mon, 13 Aug 2012 12:21:52 -0400 > > > >> From: arc...@gmail.com > >> To: factor-talk@lists.sourceforge.net > >> Subject: Re: [Factor-talk] Any way of making sense of what's in the boot > >> image? > >> > >> On Mon, Aug 13, 2012 at 11:52 AM, Michael Clagett > >> wrote: > >> > Here's an obscure question that is of interest to me in my current > >> > quest, > >> > but probably not to anyone else. So if there is a better forum for me to > >> > ask such things, I would love to be instructed; until I hear otherwise, > >> > however, I will continue to use this list. > >> > > >> > Is there any place where I can penetrate the meaning of the following > >> > constants: > >> > > >> > CONSTANT: rt-dlsym 0 > >> > CONSTANT: rt-entry-point 1 > >> > CONSTANT: rt-entry-point-pic 2 > >> > CONSTANT: rt-entry-point-pic-tail 3 > >> > CONSTANT: rt-here 4 > >> > CONSTANT: rt-this 5 > >> > CONSTANT: rt-literal 6 > >> > CONSTANT: rt-untagged 7 > >> > CONSTANT: rt-megamorphic-cache-hits 8 > >> > CONSTANT: rt-vm 9 > >> > CONSTANT: rt-cards-offset 10 > >> > CONSTANT: rt-decks-offset 11 > >> > CONSTANT: rt-exception-handler 12 > >> > CONSTANT: rt-dlsym-toc 13 > >> > CONSTANT: rt-inline-cache-miss 14 > >> > CONSTANT: rt-safepoint 15 > >> > > >> > So far I've only encountered rt-here and I've only seen it encoded into > >> > a > >> > relocation entry and not really used anywhere yet. But this strikes me > >> > as > >> > the kind of thing it would be useful to know as I am slogging through > >> > this > >> > stuff. > >> > > >> > Not a hugely pressing question, as I'm sure I'll muddle through it. But > >> > if > >> > anyone has a moment to illuminate, it would be nice. > >> > >> Those are relocation record types. When the compiler generates code > >> for a word, it also needs to generate relocation entries every time it > >> references another word in a jump or call statement, much like a > >> native C compiler needs to do for symbols in other modules. > >> The VM uses these relocation entries to update the operands of jump > >> and call instructions when code is written to the code heap, when the > >> code heap is compacted, or if code is moved in memory for any reason. > >> The different rt-* constants are used to describe what kind of object > >> a relocation refers to, such as a foreign function in a DLL (dlsym), a > >> word entry point (entry-point-*), the current address (here), etc. > >> > >> -Joe > >> > >> > >> -- > >> Live Security Virtual Conference > >> Exclusive live event will cover all the ways today's security and > >> threat landscape has changed and how IT managers can respond. Discussions > >> will include endpoint security, mobile security and the latest in malware > >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > >> ___ > >> Factor-talk mailing list > >> Factor-talk@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/factor-talk > > > > --
Re: [Factor-talk] Any way of making sense of what's in the boot image?
yes. I've come back to haunt y'all. > Date: Mon, 13 Aug 2012 09:50:04 -0700 > From: doug.cole...@gmail.com > To: factor-talk@lists.sourceforge.net > Subject: Re: [Factor-talk] Any way of making sense of what's in the boot > image? > > Is this you? > > http://www.clarkprosecutor.org/html/death/US/clagett651.htm > > On Mon, Aug 13, 2012 at 9:46 AM, Michael Clagett wrote: > > Thank you, Joe, for the quick response. It was actually the information in > > the "such as" clause of your last sentence that I was looking for. I don't > > mean for you to take the time out to document the meaning of these different > > constants, but if it is documented somewhere other than in the creators' > > heads, I would love to be directed to it. Not a big deal, because I'm sure > > that when I get to seeing them used in the boot-image initialization code, > > all will become clear. Still, it might help me better understand what's > > being done at the make-image level to know. > >> Date: Mon, 13 Aug 2012 12:21:52 -0400 > > > >> From: arc...@gmail.com > >> To: factor-talk@lists.sourceforge.net > >> Subject: Re: [Factor-talk] Any way of making sense of what's in the boot > >> image? > >> > >> On Mon, Aug 13, 2012 at 11:52 AM, Michael Clagett > >> wrote: > >> > Here's an obscure question that is of interest to me in my current > >> > quest, > >> > but probably not to anyone else. So if there is a better forum for me to > >> > ask such things, I would love to be instructed; until I hear otherwise, > >> > however, I will continue to use this list. > >> > > >> > Is there any place where I can penetrate the meaning of the following > >> > constants: > >> > > >> > CONSTANT: rt-dlsym 0 > >> > CONSTANT: rt-entry-point 1 > >> > CONSTANT: rt-entry-point-pic 2 > >> > CONSTANT: rt-entry-point-pic-tail 3 > >> > CONSTANT: rt-here 4 > >> > CONSTANT: rt-this 5 > >> > CONSTANT: rt-literal 6 > >> > CONSTANT: rt-untagged 7 > >> > CONSTANT: rt-megamorphic-cache-hits 8 > >> > CONSTANT: rt-vm 9 > >> > CONSTANT: rt-cards-offset 10 > >> > CONSTANT: rt-decks-offset 11 > >> > CONSTANT: rt-exception-handler 12 > >> > CONSTANT: rt-dlsym-toc 13 > >> > CONSTANT: rt-inline-cache-miss 14 > >> > CONSTANT: rt-safepoint 15 > >> > > >> > So far I've only encountered rt-here and I've only seen it encoded into > >> > a > >> > relocation entry and not really used anywhere yet. But this strikes me > >> > as > >> > the kind of thing it would be useful to know as I am slogging through > >> > this > >> > stuff. > >> > > >> > Not a hugely pressing question, as I'm sure I'll muddle through it. But > >> > if > >> > anyone has a moment to illuminate, it would be nice. > >> > >> Those are relocation record types. When the compiler generates code > >> for a word, it also needs to generate relocation entries every time it > >> references another word in a jump or call statement, much like a > >> native C compiler needs to do for symbols in other modules. > >> The VM uses these relocation entries to update the operands of jump > >> and call instructions when code is written to the code heap, when the > >> code heap is compacted, or if code is moved in memory for any reason. > >> The different rt-* constants are used to describe what kind of object > >> a relocation refers to, such as a foreign function in a DLL (dlsym), a > >> word entry point (entry-point-*), the current address (here), etc. > >> > >> -Joe > >> > >> > >> -- > >> Live Security Virtual Conference > >> Exclusive live event will cover all the ways today's security and > >> threat landscape has changed and how IT managers can respond. Discussions > >> will include endpoint security, mobile security and the latest in malware > >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > >> ___ > >> Factor-talk mailing list > >> Factor-talk@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/factor-talk > > > > --
Re: [Factor-talk] Any way of making sense of what's in the boot image?
Is this you? http://www.clarkprosecutor.org/html/death/US/clagett651.htm On Mon, Aug 13, 2012 at 9:46 AM, Michael Clagett wrote: > Thank you, Joe, for the quick response. It was actually the information in > the "such as" clause of your last sentence that I was looking for. I don't > mean for you to take the time out to document the meaning of these different > constants, but if it is documented somewhere other than in the creators' > heads, I would love to be directed to it. Not a big deal, because I'm sure > that when I get to seeing them used in the boot-image initialization code, > all will become clear. Still, it might help me better understand what's > being done at the make-image level to know. >> Date: Mon, 13 Aug 2012 12:21:52 -0400 > >> From: arc...@gmail.com >> To: factor-talk@lists.sourceforge.net >> Subject: Re: [Factor-talk] Any way of making sense of what's in the boot >> image? >> >> On Mon, Aug 13, 2012 at 11:52 AM, Michael Clagett >> wrote: >> > Here's an obscure question that is of interest to me in my current >> > quest, >> > but probably not to anyone else. So if there is a better forum for me to >> > ask such things, I would love to be instructed; until I hear otherwise, >> > however, I will continue to use this list. >> > >> > Is there any place where I can penetrate the meaning of the following >> > constants: >> > >> > CONSTANT: rt-dlsym 0 >> > CONSTANT: rt-entry-point 1 >> > CONSTANT: rt-entry-point-pic 2 >> > CONSTANT: rt-entry-point-pic-tail 3 >> > CONSTANT: rt-here 4 >> > CONSTANT: rt-this 5 >> > CONSTANT: rt-literal 6 >> > CONSTANT: rt-untagged 7 >> > CONSTANT: rt-megamorphic-cache-hits 8 >> > CONSTANT: rt-vm 9 >> > CONSTANT: rt-cards-offset 10 >> > CONSTANT: rt-decks-offset 11 >> > CONSTANT: rt-exception-handler 12 >> > CONSTANT: rt-dlsym-toc 13 >> > CONSTANT: rt-inline-cache-miss 14 >> > CONSTANT: rt-safepoint 15 >> > >> > So far I've only encountered rt-here and I've only seen it encoded into >> > a >> > relocation entry and not really used anywhere yet. But this strikes me >> > as >> > the kind of thing it would be useful to know as I am slogging through >> > this >> > stuff. >> > >> > Not a hugely pressing question, as I'm sure I'll muddle through it. But >> > if >> > anyone has a moment to illuminate, it would be nice. >> >> Those are relocation record types. When the compiler generates code >> for a word, it also needs to generate relocation entries every time it >> references another word in a jump or call statement, much like a >> native C compiler needs to do for symbols in other modules. >> The VM uses these relocation entries to update the operands of jump >> and call instructions when code is written to the code heap, when the >> code heap is compacted, or if code is moved in memory for any reason. >> The different rt-* constants are used to describe what kind of object >> a relocation refers to, such as a foreign function in a DLL (dlsym), a >> word entry point (entry-point-*), the current address (here), etc. >> >> -Joe >> >> >> -- >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> ___ >> Factor-talk mailing list >> Factor-talk@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/factor-talk > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > Factor-talk mailing list > Factor-talk@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/factor-talk > -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Any way of making sense of what's in the boot image?
Thank you, Joe, for the quick response. It was actually the information in the "such as" clause of your last sentence that I was looking for. I don't mean for you to take the time out to document the meaning of these different constants, but if it is documented somewhere other than in the creators' heads, I would love to be directed to it. Not a big deal, because I'm sure that when I get to seeing them used in the boot-image initialization code, all will become clear. Still, it might help me better understand what's being done at the make-image level to know. > Date: Mon, 13 Aug 2012 12:21:52 -0400 > From: arc...@gmail.com > To: factor-talk@lists.sourceforge.net > Subject: Re: [Factor-talk] Any way of making sense of what's in the boot > image? > > On Mon, Aug 13, 2012 at 11:52 AM, Michael Clagett > wrote: > > Here's an obscure question that is of interest to me in my current quest, > > but probably not to anyone else. So if there is a better forum for me to > > ask such things, I would love to be instructed; until I hear otherwise, > > however, I will continue to use this list. > > > > Is there any place where I can penetrate the meaning of the following > > constants: > > > > CONSTANT: rt-dlsym 0 > > CONSTANT: rt-entry-point 1 > > CONSTANT: rt-entry-point-pic 2 > > CONSTANT: rt-entry-point-pic-tail 3 > > CONSTANT: rt-here 4 > > CONSTANT: rt-this 5 > > CONSTANT: rt-literal 6 > > CONSTANT: rt-untagged 7 > > CONSTANT: rt-megamorphic-cache-hits 8 > > CONSTANT: rt-vm 9 > > CONSTANT: rt-cards-offset 10 > > CONSTANT: rt-decks-offset 11 > > CONSTANT: rt-exception-handler 12 > > CONSTANT: rt-dlsym-toc 13 > > CONSTANT: rt-inline-cache-miss 14 > > CONSTANT: rt-safepoint 15 > > > > So far I've only encountered rt-here and I've only seen it encoded into a > > relocation entry and not really used anywhere yet. But this strikes me as > > the kind of thing it would be useful to know as I am slogging through this > > stuff. > > > > Not a hugely pressing question, as I'm sure I'll muddle through it. But if > > anyone has a moment to illuminate, it would be nice. > > Those are relocation record types. When the compiler generates code > for a word, it also needs to generate relocation entries every time it > references another word in a jump or call statement, much like a > native C compiler needs to do for symbols in other modules. > The VM uses these relocation entries to update the operands of jump > and call instructions when code is written to the code heap, when the > code heap is compacted, or if code is moved in memory for any reason. > The different rt-* constants are used to describe what kind of object > a relocation refers to, such as a foreign function in a DLL (dlsym), a > word entry point (entry-point-*), the current address (here), etc. > > -Joe > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > Factor-talk mailing list > Factor-talk@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/factor-talk -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Any way of making sense of what's in the boot image?
On Mon, Aug 13, 2012 at 11:52 AM, Michael Clagett wrote: > Here's an obscure question that is of interest to me in my current quest, > but probably not to anyone else. So if there is a better forum for me to > ask such things, I would love to be instructed; until I hear otherwise, > however, I will continue to use this list. > > Is there any place where I can penetrate the meaning of the following > constants: > > CONSTANT: rt-dlsym 0 > CONSTANT: rt-entry-point 1 > CONSTANT: rt-entry-point-pic 2 > CONSTANT: rt-entry-point-pic-tail 3 > CONSTANT: rt-here 4 > CONSTANT: rt-this 5 > CONSTANT: rt-literal 6 > CONSTANT: rt-untagged 7 > CONSTANT: rt-megamorphic-cache-hits 8 > CONSTANT: rt-vm 9 > CONSTANT: rt-cards-offset 10 > CONSTANT: rt-decks-offset 11 > CONSTANT: rt-exception-handler 12 > CONSTANT: rt-dlsym-toc 13 > CONSTANT: rt-inline-cache-miss 14 > CONSTANT: rt-safepoint 15 > > So far I've only encountered rt-here and I've only seen it encoded into a > relocation entry and not really used anywhere yet. But this strikes me as > the kind of thing it would be useful to know as I am slogging through this > stuff. > > Not a hugely pressing question, as I'm sure I'll muddle through it. But if > anyone has a moment to illuminate, it would be nice. Those are relocation record types. When the compiler generates code for a word, it also needs to generate relocation entries every time it references another word in a jump or call statement, much like a native C compiler needs to do for symbols in other modules. The VM uses these relocation entries to update the operands of jump and call instructions when code is written to the code heap, when the code heap is compacted, or if code is moved in memory for any reason. The different rt-* constants are used to describe what kind of object a relocation refers to, such as a foreign function in a DLL (dlsym), a word entry point (entry-point-*), the current address (here), etc. -Joe -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Any way of making sense of what's in the boot image?
Those look like VM constants. A quick grep yields where an enum is defined in a header file that has comments about their purposes: $ find -name \*.hpp | xargs grep -l "RT_DLSYM" ./vm/instruction_operands.hpp Regards, --Alex Vondrak From: Michael Clagett [mclag...@hotmail.com] Sent: Monday, August 13, 2012 8:52 AM To: Factor-Talk Subject: [MARKETING] Re: [Factor-talk] Any way of making sense of what's in the boot image? Here's an obscure question that is of interest to me in my current quest, but probably not to anyone else. So if there is a better forum for me to ask such things, I would love to be instructed; until I hear otherwise, however, I will continue to use this list. Is there any place where I can penetrate the meaning of the following constants: CONSTANT: rt-dlsym 0 CONSTANT: rt-entry-point 1 CONSTANT: rt-entry-point-pic 2 CONSTANT: rt-entry-point-pic-tail 3 CONSTANT: rt-here 4 CONSTANT: rt-this 5 CONSTANT: rt-literal 6 CONSTANT: rt-untagged 7 CONSTANT: rt-megamorphic-cache-hits 8 CONSTANT: rt-vm 9 CONSTANT: rt-cards-offset 10 CONSTANT: rt-decks-offset 11 CONSTANT: rt-exception-handler 12 CONSTANT: rt-dlsym-toc 13 CONSTANT: rt-inline-cache-miss 14 CONSTANT: rt-safepoint 15 So far I've only encountered rt-here and I've only seen it encoded into a relocation entry and not really used anywhere yet. But this strikes me as the kind of thing it would be useful to know as I am slogging through this stuff. Not a hugely pressing question, as I'm sure I'll muddle through it. But if anyone has a moment to illuminate, it would be nice. Thanks. Mike > Date: Thu, 9 Aug 2012 06:26:54 -0700 > From: arc...@gmail.com > To: factor-talk@lists.sourceforge.net > Subject: Re: [Factor-talk] Any way of making sense of what's in the boot > image? > > On Wed, Aug 8, 2012 at 9:56 PM, Michael Clagett wrote: > > Hi Joe -- > > > > Thank you so much for your guidance. I'm assuming that it is the > > basis\bootstrap\image\image.factor and the core\bootstrap\primitives.factor, > > stage1.factor and syntax.factor that you are referring to? > > > > One question just to help me get oriented before I go into heavy > > head-twisting mode. I notice that all these files have significant numbers > > of pre-existing vocabularies that they use. If this is what is used to > > generate the early stage1 bootstrapping stuff, then am I correct to assume > > that this is done from some version of factor where all this stuff has built > > already from scratch (that would be the implication, if all these files are > > able to use those vocabularies)? Or is there some other mechanism at work > > here that I should know about, and if so, is it written up anywhere that you > > know about. > > > > I have just read Slava's January 2010 post on the bootstrapping mechanism, > > so I understand the mechanism a bit better now, but am still thinking there > > has to be some Factor system somewhere that was built without a bootstrap > > image in order to have the vocabularies available that are used to generate > > the bootstrapping. Is there anything anywhere documenting that aspect of > > the picture. The reason I ask is that I would like to get a sense of how > > extensive that core fundamental set of vocabularies is that is needed to > > process the primitives and stage1 factor files. > > > > Here's the USING statement for primitives.factor: > > > > USING: alien alien.strings arrays byte-arrays generic hashtables > > hashtables.private io io.encodings.ascii kernel math > > math.private math.order namespaces make parser sequences strings > > vectors words quotations assocs layouts classes classes.private > > classes.builtin classes.singleton classes.tuple > > classes.tuple.private kernel.private vocabs vocabs.loader > > source-files definitions slots classes.union > > classes.intersection classes.predicate compiler.units > > bootstrap.image.private io.files accessors combinators ; > > IN: bootstrap.primitives > > > > It's got a lot of stuff there. Is a lot of this built in the C++ code that > > constitutes the VM? Or is some fundamental processing capability put into > > place that allows the processing of factor files to build these > > vocabularies? And if so, is the factor source used also included in the > > downloaded platform? Or was this a special primordial code base that was > > used once and never really needed again? > > Although core/bootstrap/primitives.factor is in core/, it's not > actually loaded as-is into the boot image; it's really a script > designed to run as part of `make-image` in the host image. Al
Re: [Factor-talk] Any way of making sense of what's in the boot image?
Here's an obscure question that is of interest to me in my current quest, but probably not to anyone else. So if there is a better forum for me to ask such things, I would love to be instructed; until I hear otherwise, however, I will continue to use this list. Is there any place where I can penetrate the meaning of the following constants: CONSTANT: rt-dlsym 0CONSTANT: rt-entry-point 1CONSTANT: rt-entry-point-pic 2CONSTANT: rt-entry-point-pic-tail 3CONSTANT: rt-here 4CONSTANT: rt-this 5CONSTANT: rt-literal 6CONSTANT: rt-untagged 7CONSTANT: rt-megamorphic-cache-hits 8CONSTANT: rt-vm 9CONSTANT: rt-cards-offset 10CONSTANT: rt-decks-offset 11CONSTANT: rt-exception-handler 12CONSTANT: rt-dlsym-toc 13CONSTANT: rt-inline-cache-miss 14CONSTANT: rt-safepoint 15 So far I've only encountered rt-here and I've only seen it encoded into a relocation entry and not really used anywhere yet. But this strikes me as the kind of thing it would be useful to know as I am slogging through this stuff. Not a hugely pressing question, as I'm sure I'll muddle through it. But if anyone has a moment to illuminate, it would be nice. Thanks. Mike > Date: Thu, 9 Aug 2012 06:26:54 -0700 > From: arc...@gmail.com > To: factor-talk@lists.sourceforge.net > Subject: Re: [Factor-talk] Any way of making sense of what's in the boot > image? > > On Wed, Aug 8, 2012 at 9:56 PM, Michael Clagett wrote: > > Hi Joe -- > > > > Thank you so much for your guidance. I'm assuming that it is the > > basis\bootstrap\image\image.factor and the core\bootstrap\primitives.factor, > > stage1.factor and syntax.factor that you are referring to? > > > > One question just to help me get oriented before I go into heavy > > head-twisting mode. I notice that all these files have significant numbers > > of pre-existing vocabularies that they use. If this is what is used to > > generate the early stage1 bootstrapping stuff, then am I correct to assume > > that this is done from some version of factor where all this stuff has built > > already from scratch (that would be the implication, if all these files are > > able to use those vocabularies)? Or is there some other mechanism at work > > here that I should know about, and if so, is it written up anywhere that you > > know about. > > > > I have just read Slava's January 2010 post on the bootstrapping mechanism, > > so I understand the mechanism a bit better now, but am still thinking there > > has to be some Factor system somewhere that was built without a bootstrap > > image in order to have the vocabularies available that are used to generate > > the bootstrapping. Is there anything anywhere documenting that aspect of > > the picture. The reason I ask is that I would like to get a sense of how > > extensive that core fundamental set of vocabularies is that is needed to > > process the primitives and stage1 factor files. > > > > Here's the USING statement for primitives.factor: > > > > USING: alien alien.strings arrays byte-arrays generic hashtables > > hashtables.private io io.encodings.ascii kernel math > > math.private math.order namespaces make parser sequences strings > > vectors words quotations assocs layouts classes classes.private > > classes.builtin classes.singleton classes.tuple > > classes.tuple.private kernel.private vocabs vocabs.loader > > source-files definitions slots classes.union > > classes.intersection classes.predicate compiler.units > > bootstrap.image.private io.files accessors combinators ; > > IN: bootstrap.primitives > > > > It's got a lot of stuff there. Is a lot of this built in the C++ code that > > constitutes the VM? Or is some fundamental processing capability put into > > place that allows the processing of factor files to build these > > vocabularies? And if so, is the factor source used also included in the > > downloaded platform? Or was this a special primordial code base that was > > used once and never really needed again? > > Although core/bootstrap/primitives.factor is in core/, it's not > actually loaded as-is into the boot image; it's really a script > designed to run as part of `make-image` in the host image. All of > those modules are loaded and run in the host image. While there of > course had to have been a primordial Factor that could boot itself, I > think it would be too different now to resemble current Factor. > Factor's bootstrapping loop evolved somewhat organically. > > You can tell whether a word is a C++ primitive by `see`ing it in the > listener. Primitive words show up as `PRIMITIVE:` when prettyprinted. > > At a high level, `make-i
Re: [Factor-talk] Any way of making sense of what's in the boot image?
./factor starts Factor from the command-line. If you're on mac, you get a terminal listener (to start it right, you want to run it from the app: ./Factor.app/Contents/MacOS/factor); if you're on linux, you get the UI. In Windows, you run factor.com and it launches the UI. So in whatever REPL (read-eval-print loop), if you then type ``die'', then you get a FEP in the terminal you launched Factor from. A FEP is basically the error shell you get when Factor has some kind of crash, but in this case, we called it intentionally. So you can type ``help'' and get a list of options, but what we want is to find the machine addresses for all the Factor words. So we type ``words'' and you see a list of machine addresses associated with Factor words. Then you can type ``c'' and continue execution, since we didn't really crash but invoked the FEP on purpose. Doug On Fri, Aug 10, 2012 at 3:05 PM, Michael Clagett wrote: > Doug, thank you for your help, but I'm afraid I didn't understand everything > in your response. Not sure of the context of your instructions. Not sure, > for example, what you mean by ./factor (is this something I'm supposed to > type somewhere?), what you mean by in the repl: die (not sure what the > "repl" is -- or what "die" means for that matter), and then what you mean by > the "shell". Other than that I understood you completely :) . > >> Date: Fri, 10 Aug 2012 14:57:51 -0700 >> From: doug.cole...@gmail.com > >> To: factor-talk@lists.sourceforge.net >> Subject: Re: [Factor-talk] Any way of making sense of what's in the boot >> image? >> >> You can do this: >> >> ./factor >> in the repl: die >> then in the shell: >> words >> >> It dumps a list of word addresses in Factor. >> >> This works for words, but not quotations. >> >> Hope this helps. >> >> Doug >> >> On Fri, Aug 10, 2012 at 2:55 PM, Michael Clagett >> wrote: >> > One more question before I disappear. I've been tracing through the >> > bootstrapping code with WinDbg and am currently in >> > factor_vm::compile_all_words where a loop is about to compile 4894 >> > words. >> > These are accessible as words, which in turn can server up their >> > definitions >> > (via word->def). These are quotations, which, like words, display in the >> > debugger inspector as a fairly simple structure with a "value" and >> > "parent_slot". I'm wondering if by some small chance there is some way >> > to >> > navigate back to the symbolic name for any words that one comes across >> > in >> > this fashion. Certainly one could get away with compiling simply with >> > the >> > type and value and never need the symbolic name, which I suspect is what >> > is >> > being done. So I don't have high hopes, but it certainly doesn't hurt to >> > ask. >> > >> > >> > From: mclag...@hotmail.com >> > To: factor-talk@lists.sourceforge.net >> > Date: Fri, 10 Aug 2012 21:16:40 +0000 >> > >> > Subject: Re: [Factor-talk] Any way of making sense of what's in the boot >> > image? >> > >> > For anyone else who might happen onto the problem I had, the solution >> > ended >> > up being that my architecture was named "windows-x86.32", not "x86.32". >> > >> > >> > >> > From: mrj...@gmail.com >> > Date: Fri, 10 Aug 2012 14:10:41 -0700 >> > To: factor-talk@lists.sourceforge.net >> > Subject: Re: [Factor-talk] Any way of making sense of what's in the boot >> > image? >> > >> > Write "my-arch make-image" in listener. >> > >> > Then type Ctrl-W to walk it. >> > >> > "Step" across my-arch >> > >> > "Into" into make-image >> > >> > Rinse, repeat. :) >> > >> > >> > On Fri, Aug 10, 2012 at 2:08 PM, Michael Clagett >> > wrote: >> > >> > Quick question, if you're still on the horn. How do I trace into myarch >> > make-image from the Listener. If I hit enter it just executes. I'm sure >> > there must be any easy way to step into it, which I'm sure I can find by >> > searching the documentation. But perhaps you could save me five minutes. >> > >> > >> > From: mrj...@gmail.com >> &
Re: [Factor-talk] Any way of making sense of what's in the boot image?
Doug, thank you for your help, but I'm afraid I didn't understand everything in your response. Not sure of the context of your instructions. Not sure, for example, what you mean by ./factor (is this something I'm supposed to type somewhere?), what you mean by in the repl: die (not sure what the "repl" is -- or what "die" means for that matter), and then what you mean by the "shell". Other than that I understood you completely :) . > Date: Fri, 10 Aug 2012 14:57:51 -0700 > From: doug.cole...@gmail.com > To: factor-talk@lists.sourceforge.net > Subject: Re: [Factor-talk] Any way of making sense of what's in the boot > image? > > You can do this: > > ./factor > in the repl: die > then in the shell: > words > > It dumps a list of word addresses in Factor. > > This works for words, but not quotations. > > Hope this helps. > > Doug > > On Fri, Aug 10, 2012 at 2:55 PM, Michael Clagett wrote: > > One more question before I disappear. I've been tracing through the > > bootstrapping code with WinDbg and am currently in > > factor_vm::compile_all_words where a loop is about to compile 4894 words. > > These are accessible as words, which in turn can server up their definitions > > (via word->def). These are quotations, which, like words, display in the > > debugger inspector as a fairly simple structure with a "value" and > > "parent_slot". I'm wondering if by some small chance there is some way to > > navigate back to the symbolic name for any words that one comes across in > > this fashion. Certainly one could get away with compiling simply with the > > type and value and never need the symbolic name, which I suspect is what is > > being done. So I don't have high hopes, but it certainly doesn't hurt to > > ask. > > > > > > From: mclag...@hotmail.com > > To: factor-talk@lists.sourceforge.net > > Date: Fri, 10 Aug 2012 21:16:40 + > > > > Subject: Re: [Factor-talk] Any way of making sense of what's in the boot > > image? > > > > For anyone else who might happen onto the problem I had, the solution ended > > up being that my architecture was named "windows-x86.32", not "x86.32". > > > > > > > > From: mrj...@gmail.com > > Date: Fri, 10 Aug 2012 14:10:41 -0700 > > To: factor-talk@lists.sourceforge.net > > Subject: Re: [Factor-talk] Any way of making sense of what's in the boot > > image? > > > > Write "my-arch make-image" in listener. > > > > Then type Ctrl-W to walk it. > > > > "Step" across my-arch > > > > "Into" into make-image > > > > Rinse, repeat. :) > > > > > > On Fri, Aug 10, 2012 at 2:08 PM, Michael Clagett > > wrote: > > > > Quick question, if you're still on the horn. How do I trace into myarch > > make-image from the Listener. If I hit enter it just executes. I'm sure > > there must be any easy way to step into it, which I'm sure I can find by > > searching the documentation. But perhaps you could save me five minutes. > > > > > > From: mrj...@gmail.com > > Date: Fri, 10 Aug 2012 14:01:58 -0700 > > > > To: factor-talk@lists.sourceforge.net > > Subject: Re: [Factor-talk] Any way of making sense of what's in the boot > > image? > > > > Typically the architecture is a combination of os and arch: > > > > IN: scratchpad my-arch . > > "unix-x86.64" > > > > You can use the "my-arch" word to make an image for your architecture: > > > > IN: scratchpad my-arch make-image > > > > > > > > On Fri, Aug 10, 2012 at 1:56 PM, Michael Clagett > > wrote: > > > > Hi -- > > > > I've been trying to run the make-image word from the Listener and got as far > > as this trace: > > > > IN: scratchpad Command: restart > > 1: Note: > > Added "bootstrap.image" vocabulary to search path > > "x86.32" make-image > > Loading resource:/core/bootstrap/stage1.factor > > Bootstrap stage 1... > > Loading vocab:bootstrap/primitives.factor > > Creating primitives and basic runtime structures... > > Loading vocab:bootstrap/syntax.factor > > > > From Traceback: > > > > Data Stack: > > > > [ ~quotation~ with-compilation-unit ] > > "Bad architecture:
Re: [Factor-talk] Any way of making sense of what's in the boot image?
You can do this:
./factor
in the repl: die
then in the shell:
words
It dumps a list of word addresses in Factor.
This works for words, but not quotations.
Hope this helps.
Doug
On Fri, Aug 10, 2012 at 2:55 PM, Michael Clagett wrote:
> One more question before I disappear. I've been tracing through the
> bootstrapping code with WinDbg and am currently in
> factor_vm::compile_all_words where a loop is about to compile 4894 words.
> These are accessible as words, which in turn can server up their definitions
> (via word->def). These are quotations, which, like words, display in the
> debugger inspector as a fairly simple structure with a "value" and
> "parent_slot". I'm wondering if by some small chance there is some way to
> navigate back to the symbolic name for any words that one comes across in
> this fashion. Certainly one could get away with compiling simply with the
> type and value and never need the symbolic name, which I suspect is what is
> being done. So I don't have high hopes, but it certainly doesn't hurt to
> ask.
>
>
> From: mclag...@hotmail.com
> To: factor-talk@lists.sourceforge.net
> Date: Fri, 10 Aug 2012 21:16:40 +
>
> Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
> image?
>
> For anyone else who might happen onto the problem I had, the solution ended
> up being that my architecture was named "windows-x86.32", not "x86.32".
>
>
> ________________________
> From: mrj...@gmail.com
> Date: Fri, 10 Aug 2012 14:10:41 -0700
> To: factor-talk@lists.sourceforge.net
> Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
> image?
>
> Write "my-arch make-image" in listener.
>
> Then type Ctrl-W to walk it.
>
> "Step" across my-arch
>
> "Into" into make-image
>
> Rinse, repeat. :)
>
>
> On Fri, Aug 10, 2012 at 2:08 PM, Michael Clagett
> wrote:
>
> Quick question, if you're still on the horn. How do I trace into myarch
> make-image from the Listener. If I hit enter it just executes. I'm sure
> there must be any easy way to step into it, which I'm sure I can find by
> searching the documentation. But perhaps you could save me five minutes.
>
>
> From: mrj...@gmail.com
> Date: Fri, 10 Aug 2012 14:01:58 -0700
>
> To: factor-talk@lists.sourceforge.net
> Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
> image?
>
> Typically the architecture is a combination of os and arch:
>
> IN: scratchpad my-arch .
> "unix-x86.64"
>
> You can use the "my-arch" word to make an image for your architecture:
>
> IN: scratchpad my-arch make-image
>
>
>
> On Fri, Aug 10, 2012 at 1:56 PM, Michael Clagett
> wrote:
>
> Hi --
>
> I've been trying to run the make-image word from the Listener and got as far
> as this trace:
>
> IN: scratchpad Command: restart
> 1: Note:
> Added "bootstrap.image" vocabulary to search path
> "x86.32" make-image
> Loading resource:/core/bootstrap/stage1.factor
> Bootstrap stage 1...
> Loading vocab:bootstrap/primitives.factor
> Creating primitives and basic runtime structures...
> Loading vocab:bootstrap/syntax.factor
>
> From Traceback:
>
> Data Stack:
>
> [ ~quotation~ with-compilation-unit ]
> "Bad architecture: x86.32"
>
> Call Stack:
>
> (U)
> Quotation: [ set-namestack init-catchstack self quot>> call -> stop ]
> (O)
> Word: listener-thread
> (O)
> Word: listener
> (O)
> Word: (listener)
> (U)
> Quotation: [
> [ ~quotation~ dip swap ~quotation~ dip ] dip swap
> [ call datastack ] dip -> swap [ set-datastack ] dip
> ]
> (U)
> Quotation: [ call -> datastack ]
> (O)
> Word: make-image
> (U)
> Quotation: [
> "Bootstrap stage 1..." print
> flush "vocab:bootstrap/primitives.factor" run-file
> -> load-help? off { "resource:core" } vocab-roots set [
> ~quotation~ % "math.integers" require
> "math.floats" require "memory" require
> "io.streams.c" require "vocabs.loader" require
> "syntax" require "bootstrap.layouts" require
> ~quotation~ %
> ] [ ] make bootstrap-startup-quot set
> ]
> (U)
> Quotation: [
> "Creating primitives and basic runtime structures..." print
> flush H{ } clone sub-primitives set
> "vocab:bootstrap/syntax.factor" parse-file ar
Re: [Factor-talk] Any way of making sense of what's in the boot image?
One more question before I disappear. I've been tracing through the
bootstrapping code with WinDbg and am currently in factor_vm::compile_all_words
where a loop is about to compile 4894 words. These are accessible as words,
which in turn can server up their definitions (via word->def). These are
quotations, which, like words, display in the debugger inspector as a fairly
simple structure with a "value" and "parent_slot". I'm wondering if by some
small chance there is some way to navigate back to the symbolic name for any
words that one comes across in this fashion. Certainly one could get away with
compiling simply with the type and value and never need the symbolic name,
which I suspect is what is being done. So I don't have high hopes, but it
certainly doesn't hurt to ask.
From: mclag...@hotmail.com
To: factor-talk@lists.sourceforge.net
Date: Fri, 10 Aug 2012 21:16:40 +
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot image?
For anyone else who might happen onto the problem I had, the solution ended up
being that my architecture was named "windows-x86.32", not "x86.32".
From: mrj...@gmail.com
Date: Fri, 10 Aug 2012 14:10:41 -0700
To: factor-talk@lists.sourceforge.net
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
image?
Write "my-arch make-image" in listener.
Then type Ctrl-W to walk it.
"Step" across my-arch
"Into" into make-image
Rinse, repeat. :)
On Fri, Aug 10, 2012 at 2:08 PM, Michael Clagett wrote:
Quick question, if you're still on the horn. How do I trace into myarch
make-image from the Listener. If I hit enter it just executes. I'm sure there
must be any easy way to step into it, which I'm sure I can find by searching
the documentation. But perhaps you could save me five minutes.
From: mrj...@gmail.com
Date: Fri, 10 Aug 2012 14:01:58 -0700
To: factor-talk@lists.sourceforge.net
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
image?
Typically the architecture is a combination of os and arch:
IN: scratchpad my-arch ."unix-x86.64"
You can use the "my-arch" word to make an image for your architecture:
IN: scratchpad my-arch make-image
On Fri, Aug 10, 2012 at 1:56 PM, Michael Clagett wrote:
Hi --
I've been trying to run the make-image word from the Listener and got as far as
this trace:
IN: scratchpad Command: restart
1: Note:
Added "bootstrap.image" vocabulary to search path
"x86.32" make-image
Loading resource:/core/bootstrap/stage1.factor
Bootstrap stage 1...
Loading vocab:bootstrap/primitives.factor
Creating primitives and basic runtime structures...
Loading vocab:bootstrap/syntax.factor
>From Traceback:
Data Stack:
[ ~quotation~ with-compilation-unit ]
"Bad architecture: x86.32"
Call Stack:
(U)
Quotation: [ set-namestack init-catchstack self quot>> call -> stop ]
(O)
Word: listener-thread
(O)
Word: listener
(O)
Word: (listener)
(U)
Quotation: [
[ ~quotation~ dip swap ~quotation~ dip ] dip swap
[ call datastack ] dip -> swap [ set-datastack ] dip
]
(U)
Quotation: [ call -> datastack ]
(O)
Word: make-image
(U)
Quotation: [
"Bootstrap stage 1..." print
flush "vocab:bootstrap/primitives.factor" run-file
-> load-help? off { "resource:core" } vocab-roots set [
~quotation~ % "math.integers" require
"math.floats" require "memory" require
"io.streams.c" require "vocabs.loader" require
"syntax" require "bootstrap.layouts" require
~quotation~ %
] [ ] make bootstrap-startup-quot set
]
(U)
Quotation: [
"Creating primitives and basic runtime structures..." print
flush H{ } clone sub-primitives set
"vocab:bootstrap/syntax.factor" parse-file architecture get
{ ~array~ ~array~ ~array~ ~array~ ~array~ ~array~ } ?at
[ "Bad architecture: " prepend throw ] unless
-> "vocab:cpu/" "/bootstrap.factor" surround
parse-file "vocab:bootstrap/layouts/layouts.factor"
parse-file "syntax" lookup-vocab vocab-words
bootstrap-syntax set H{ } clone dictionary set
H{ } clone root-cache set H{ } clone source-files set
H{ } clone update-map set H{ } clone implementors-map set
init-caches bootstrapping? on ( -- ) call-effect
( -- ) call-effect "accessors" create-vocab drop
num-types get f builtins set [
( -- ) call-effect ~array~ ~quotation~ each
"fixnum" "math" create register-builtin
"bignum" "math" create register-builtin
"tuple&q
Re: [Factor-talk] Any way of making sense of what's in the boot image?
For anyone else who might happen onto the problem I had, the solution ended up
being that my architecture was named "windows-x86.32", not "x86.32".
From: mrj...@gmail.com
Date: Fri, 10 Aug 2012 14:10:41 -0700
To: factor-talk@lists.sourceforge.net
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
image?
Write "my-arch make-image" in listener.
Then type Ctrl-W to walk it.
"Step" across my-arch
"Into" into make-image
Rinse, repeat. :)
On Fri, Aug 10, 2012 at 2:08 PM, Michael Clagett wrote:
Quick question, if you're still on the horn. How do I trace into myarch
make-image from the Listener. If I hit enter it just executes. I'm sure there
must be any easy way to step into it, which I'm sure I can find by searching
the documentation. But perhaps you could save me five minutes.
From: mrj...@gmail.com
Date: Fri, 10 Aug 2012 14:01:58 -0700
To: factor-talk@lists.sourceforge.net
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
image?
Typically the architecture is a combination of os and arch:
IN: scratchpad my-arch ."unix-x86.64"
You can use the "my-arch" word to make an image for your architecture:
IN: scratchpad my-arch make-image
On Fri, Aug 10, 2012 at 1:56 PM, Michael Clagett wrote:
Hi --
I've been trying to run the make-image word from the Listener and got as far as
this trace:
IN: scratchpad Command: restart
1: Note:
Added "bootstrap.image" vocabulary to search path
"x86.32" make-image
Loading resource:/core/bootstrap/stage1.factor
Bootstrap stage 1...
Loading vocab:bootstrap/primitives.factor
Creating primitives and basic runtime structures...
Loading vocab:bootstrap/syntax.factor
>From Traceback:
Data Stack:
[ ~quotation~ with-compilation-unit ]
"Bad architecture: x86.32"
Call Stack:
(U)
Quotation: [ set-namestack init-catchstack self quot>> call -> stop ]
(O)
Word: listener-thread
(O)
Word: listener
(O)
Word: (listener)
(U)
Quotation: [
[ ~quotation~ dip swap ~quotation~ dip ] dip swap
[ call datastack ] dip -> swap [ set-datastack ] dip
]
(U)
Quotation: [ call -> datastack ]
(O)
Word: make-image
(U)
Quotation: [
"Bootstrap stage 1..." print
flush "vocab:bootstrap/primitives.factor" run-file
-> load-help? off { "resource:core" } vocab-roots set [
~quotation~ % "math.integers" require
"math.floats" require "memory" require
"io.streams.c" require "vocabs.loader" require
"syntax" require "bootstrap.layouts" require
~quotation~ %
] [ ] make bootstrap-startup-quot set
]
(U)
Quotation: [
"Creating primitives and basic runtime structures..." print
flush H{ } clone sub-primitives set
"vocab:bootstrap/syntax.factor" parse-file architecture get
{ ~array~ ~array~ ~array~ ~array~ ~array~ ~array~ } ?at
[ "Bad architecture: " prepend throw ] unless
-> "vocab:cpu/" "/bootstrap.factor" surround
parse-file "vocab:bootstrap/layouts/layouts.factor"
parse-file "syntax" lookup-vocab vocab-words
bootstrap-syntax set H{ } clone dictionary set
H{ } clone root-cache set H{ } clone source-files set
H{ } clone update-map set H{ } clone implementors-map set
init-caches bootstrapping? on ( -- ) call-effect
( -- ) call-effect "accessors" create-vocab drop
num-types get f builtins set [
( -- ) call-effect ~array~ ~quotation~ each
"fixnum" "math" create register-builtin
"bignum" "math" create register-builtin
"tuple" "kernel" create register-builtin
"float" "math" create register-builtin
"f" "syntax" lookup-word register-builtin
"array" "arrays" create register-builtin
"wrapper" "kernel" create register-builtin
"callstack" "kernel" create register-builtin
"string" "strings" create register-builtin
"quotation" "quotations" create register-builtin
"dll" "alien" create register-builtin
"alien" "alien" create register-builtin
"word" "words" create register-builtin
"byte-array" "byte-arrays" create register-builtin
"f" "syntax" lookup-word ~array~ define-builtin
"f" "syntax" create
~quotation~ "predicate" set-word-prop
"f?"
Re: [Factor-talk] Any way of making sense of what's in the boot image?
> > Thanks much. This should keep me occupied and out of everyone's hair for > a while. > No worries, keep the questions coming! -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Any way of making sense of what's in the boot image?
Thanks much. This should keep me occupied and out of everyone's hair for a
while.
From: mrj...@gmail.com
Date: Fri, 10 Aug 2012 14:10:41 -0700
To: factor-talk@lists.sourceforge.net
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
image?
Write "my-arch make-image" in listener.
Then type Ctrl-W to walk it.
"Step" across my-arch
"Into" into make-image
Rinse, repeat. :)
On Fri, Aug 10, 2012 at 2:08 PM, Michael Clagett wrote:
Quick question, if you're still on the horn. How do I trace into myarch
make-image from the Listener. If I hit enter it just executes. I'm sure there
must be any easy way to step into it, which I'm sure I can find by searching
the documentation. But perhaps you could save me five minutes.
From: mrj...@gmail.com
Date: Fri, 10 Aug 2012 14:01:58 -0700
To: factor-talk@lists.sourceforge.net
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
image?
Typically the architecture is a combination of os and arch:
IN: scratchpad my-arch ."unix-x86.64"
You can use the "my-arch" word to make an image for your architecture:
IN: scratchpad my-arch make-image
On Fri, Aug 10, 2012 at 1:56 PM, Michael Clagett wrote:
Hi --
I've been trying to run the make-image word from the Listener and got as far as
this trace:
IN: scratchpad Command: restart
1: Note:
Added "bootstrap.image" vocabulary to search path
"x86.32" make-image
Loading resource:/core/bootstrap/stage1.factor
Bootstrap stage 1...
Loading vocab:bootstrap/primitives.factor
Creating primitives and basic runtime structures...
Loading vocab:bootstrap/syntax.factor
>From Traceback:
Data Stack:
[ ~quotation~ with-compilation-unit ]
"Bad architecture: x86.32"
Call Stack:
(U)
Quotation: [ set-namestack init-catchstack self quot>> call -> stop ]
(O)
Word: listener-thread
(O)
Word: listener
(O)
Word: (listener)
(U)
Quotation: [
[ ~quotation~ dip swap ~quotation~ dip ] dip swap
[ call datastack ] dip -> swap [ set-datastack ] dip
]
(U)
Quotation: [ call -> datastack ]
(O)
Word: make-image
(U)
Quotation: [
"Bootstrap stage 1..." print
flush "vocab:bootstrap/primitives.factor" run-file
-> load-help? off { "resource:core" } vocab-roots set [
~quotation~ % "math.integers" require
"math.floats" require "memory" require
"io.streams.c" require "vocabs.loader" require
"syntax" require "bootstrap.layouts" require
~quotation~ %
] [ ] make bootstrap-startup-quot set
]
(U)
Quotation: [
"Creating primitives and basic runtime structures..." print
flush H{ } clone sub-primitives set
"vocab:bootstrap/syntax.factor" parse-file architecture get
{ ~array~ ~array~ ~array~ ~array~ ~array~ ~array~ } ?at
[ "Bad architecture: " prepend throw ] unless
-> "vocab:cpu/" "/bootstrap.factor" surround
parse-file "vocab:bootstrap/layouts/layouts.factor"
parse-file "syntax" lookup-vocab vocab-words
bootstrap-syntax set H{ } clone dictionary set
H{ } clone root-cache set H{ } clone source-files set
H{ } clone update-map set H{ } clone implementors-map set
init-caches bootstrapping? on ( -- ) call-effect
( -- ) call-effect "accessors" create-vocab drop
num-types get f builtins set [
( -- ) call-effect ~array~ ~quotation~ each
"fixnum" "math" create register-builtin
"bignum" "math" create register-builtin
"tuple" "kernel" create register-builtin
"float" "math" create register-builtin
"f" "syntax" lookup-word register-builtin
"array" "arrays" create register-builtin
"wrapper" "kernel" create register-builtin
"callstack" "kernel" create register-builtin
"string" "strings" create register-builtin
"quotation" "quotations" create register-builtin
"dll" "alien" create register-builtin
"alien" "alien" create register-builtin
"word" "words" create register-builtin
"byte-array" "byte-arrays" create register-builtin
"f" "syntax" lookup-word ~array~ define-builtin
"f" "syntax" create
~quotation~ "predicate" set-word-prop
"f?" "syntax" vocab-words delete-at
"t" &q
Re: [Factor-talk] Any way of making sense of what's in the boot image?
Write "my-arch make-image" in listener.
Then type Ctrl-W to walk it.
"Step" across my-arch
"Into" into make-image
Rinse, repeat. :)
On Fri, Aug 10, 2012 at 2:08 PM, Michael Clagett wrote:
> Quick question, if you're still on the horn. How do I trace into myarch
> make-image from the Listener. If I hit enter it just executes. I'm sure
> there must be any easy way to step into it, which I'm sure I can find by
> searching the documentation. But perhaps you could save me five minutes.
>
> --
> From: mrj...@gmail.com
> Date: Fri, 10 Aug 2012 14:01:58 -0700
>
> To: factor-talk@lists.sourceforge.net
> Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
> image?
>
> Typically the architecture is a combination of os and arch:
>
> IN: scratchpad my-arch .
> "unix-x86.64"
>
> You can use the "my-arch" word to make an image for your architecture:
>
> IN: scratchpad my-arch make-image
>
>
>
> On Fri, Aug 10, 2012 at 1:56 PM, Michael Clagett wrote:
>
> Hi --
>
> I've been trying to run the make-image word from the Listener and got as
> far as this trace:
>
> IN: scratchpad Command: restart
> 1: Note:
> Added "bootstrap.image" vocabulary to search path
> "x86.32" make-image
> Loading resource:/core/bootstrap/stage1.factor
> Bootstrap stage 1...
> Loading vocab:bootstrap/primitives.factor
> Creating primitives and basic runtime structures...
> Loading vocab:bootstrap/syntax.factor
>
> From Traceback:
>
> Data Stack:
>
> [ ~quotation~ with-compilation-unit ]
> "Bad architecture: x86.32"
>
> Call Stack:
>
> (U)
> Quotation: [ set-namestack init-catchstack self quot>> call -> stop ]
> (O)
> Word: listener-thread
> (O)
> Word: listener
> (O)
> Word: (listener)
> (U)
> Quotation: [
> [ ~quotation~ dip swap ~quotation~ dip ] dip swap
> [ call datastack ] dip -> swap [ set-datastack ] dip
> ]
> (U)
> Quotation: [ call -> datastack ]
> (O)
> Word: make-image
> (U)
> Quotation: [
> "Bootstrap stage 1..." print
> flush "vocab:bootstrap/primitives.factor" run-file
> -> load-help? off { "resource:core" } vocab-roots set [
> ~quotation~ % "math.integers" require
> "math.floats" require "memory" require
> "io.streams.c" require "vocabs.loader" require
> "syntax" require "bootstrap.layouts" require
> ~quotation~ %
> ] [ ] make bootstrap-startup-quot set
> ]
> (U)
> Quotation: [
> "Creating primitives and basic runtime structures..." print
> flush H{ } clone sub-primitives set
> "vocab:bootstrap/syntax.factor" parse-file architecture get
> { ~array~ ~array~ ~array~ ~array~ ~array~ ~array~ } ?at
> [ "Bad architecture: " prepend throw ] unless
> -> "vocab:cpu/" "/bootstrap.factor" surround
> parse-file "vocab:bootstrap/layouts/layouts.factor"
> parse-file "syntax" lookup-vocab vocab-words
> bootstrap-syntax set H{ } clone dictionary set
> H{ } clone root-cache set H{ } clone source-files set
> H{ } clone update-map set H{ } clone implementors-map set
> init-caches bootstrapping? on ( -- ) call-effect
> ( -- ) call-effect "accessors" create-vocab drop
> num-types get f builtins set [
> ( -- ) call-effect ~array~ ~quotation~ each
> "fixnum" "math" create register-builtin
> "bignum" "math" create register-builtin
> "tuple" "kernel" create register-builtin
> "float" "math" create register-builtin
> "f" "syntax" lookup-word register-builtin
> "array" "arrays" create register-builtin
> "wrapper" "kernel" create register-builtin
> "callstack" "kernel" create register-builtin
> "string" "strings" create register-builtin
> "quotation" "quotations" create register-builtin
> "dll" "alien" create register-builtin
> "alien" "alien" create register-builtin
> "word" "words" create register-builtin
> "byte-array" "byte-arrays" create register-builtin
> "f" "syntax" lookup-word ~array~ define-builtin
>
Re: [Factor-talk] Any way of making sense of what's in the boot image?
Quick question, if you're still on the horn. How do I trace into myarch
make-image from the Listener. If I hit enter it just executes. I'm sure there
must be any easy way to step into it, which I'm sure I can find by searching
the documentation. But perhaps you could save me five minutes.
From: mrj...@gmail.com
Date: Fri, 10 Aug 2012 14:01:58 -0700
To: factor-talk@lists.sourceforge.net
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
image?
Typically the architecture is a combination of os and arch:
IN: scratchpad my-arch ."unix-x86.64"
You can use the "my-arch" word to make an image for your architecture:
IN: scratchpad my-arch make-image
On Fri, Aug 10, 2012 at 1:56 PM, Michael Clagett wrote:
Hi --
I've been trying to run the make-image word from the Listener and got as far as
this trace:
IN: scratchpad Command: restart
1: Note:
Added "bootstrap.image" vocabulary to search path
"x86.32" make-image
Loading resource:/core/bootstrap/stage1.factor
Bootstrap stage 1...
Loading vocab:bootstrap/primitives.factor
Creating primitives and basic runtime structures...
Loading vocab:bootstrap/syntax.factor
>From Traceback:
Data Stack:
[ ~quotation~ with-compilation-unit ]
"Bad architecture: x86.32"
Call Stack:
(U)
Quotation: [ set-namestack init-catchstack self quot>> call -> stop ]
(O)
Word: listener-thread
(O)
Word: listener
(O)
Word: (listener)
(U)
Quotation: [
[ ~quotation~ dip swap ~quotation~ dip ] dip swap
[ call datastack ] dip -> swap [ set-datastack ] dip
]
(U)
Quotation: [ call -> datastack ]
(O)
Word: make-image
(U)
Quotation: [
"Bootstrap stage 1..." print
flush "vocab:bootstrap/primitives.factor" run-file
-> load-help? off { "resource:core" } vocab-roots set [
~quotation~ % "math.integers" require
"math.floats" require "memory" require
"io.streams.c" require "vocabs.loader" require
"syntax" require "bootstrap.layouts" require
~quotation~ %
] [ ] make bootstrap-startup-quot set
]
(U)
Quotation: [
"Creating primitives and basic runtime structures..." print
flush H{ } clone sub-primitives set
"vocab:bootstrap/syntax.factor" parse-file architecture get
{ ~array~ ~array~ ~array~ ~array~ ~array~ ~array~ } ?at
[ "Bad architecture: " prepend throw ] unless
-> "vocab:cpu/" "/bootstrap.factor" surround
parse-file "vocab:bootstrap/layouts/layouts.factor"
parse-file "syntax" lookup-vocab vocab-words
bootstrap-syntax set H{ } clone dictionary set
H{ } clone root-cache set H{ } clone source-files set
H{ } clone update-map set H{ } clone implementors-map set
init-caches bootstrapping? on ( -- ) call-effect
( -- ) call-effect "accessors" create-vocab drop
num-types get f builtins set [
( -- ) call-effect ~array~ ~quotation~ each
"fixnum" "math" create register-builtin
"bignum" "math" create register-builtin
"tuple" "kernel" create register-builtin
"float" "math" create register-builtin
"f" "syntax" lookup-word register-builtin
"array" "arrays" create register-builtin
"wrapper" "kernel" create register-builtin
"callstack" "kernel" create register-builtin
"string" "strings" create register-builtin
"quotation" "quotations" create register-builtin
"dll" "alien" create register-builtin
"alien" "alien" create register-builtin
"word" "words" create register-builtin
"byte-array" "byte-arrays" create register-builtin
"f" "syntax" lookup-word ~array~ define-builtin
"f" "syntax" create
~quotation~ "predicate" set-word-prop
"f?" "syntax" vocab-words delete-at
"t" "syntax" lookup-word define-singleton-class
"c-ptr" "alien" create ~quotation~ ~array~ make
define-union-class
"array-capacity" "sequences.private" create
"fixnum" "math" lookup-word
~quotation~ ~quotation~ make define-predicate-class
"array-capacity" "sequences.private" lookup-word
~195 more~
] with-compilation-unit
]
(O)
Method: M\ object throw
(U)
Quotation: [
OBJ-CURRENT-THREAD special-object error-th
Re: [Factor-talk] Any way of making sense of what's in the boot image?
Beautiful. Worked like a charm. Thanks.
From: mrj...@gmail.com
Date: Fri, 10 Aug 2012 14:01:58 -0700
To: factor-talk@lists.sourceforge.net
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
image?
Typically the architecture is a combination of os and arch:
IN: scratchpad my-arch ."unix-x86.64"
You can use the "my-arch" word to make an image for your architecture:
IN: scratchpad my-arch make-image
On Fri, Aug 10, 2012 at 1:56 PM, Michael Clagett wrote:
Hi --
I've been trying to run the make-image word from the Listener and got as far as
this trace:
IN: scratchpad Command: restart
1: Note:
Added "bootstrap.image" vocabulary to search path
"x86.32" make-image
Loading resource:/core/bootstrap/stage1.factor
Bootstrap stage 1...
Loading vocab:bootstrap/primitives.factor
Creating primitives and basic runtime structures...
Loading vocab:bootstrap/syntax.factor
>From Traceback:
Data Stack:
[ ~quotation~ with-compilation-unit ]
"Bad architecture: x86.32"
Call Stack:
(U)
Quotation: [ set-namestack init-catchstack self quot>> call -> stop ]
(O)
Word: listener-thread
(O)
Word: listener
(O)
Word: (listener)
(U)
Quotation: [
[ ~quotation~ dip swap ~quotation~ dip ] dip swap
[ call datastack ] dip -> swap [ set-datastack ] dip
]
(U)
Quotation: [ call -> datastack ]
(O)
Word: make-image
(U)
Quotation: [
"Bootstrap stage 1..." print
flush "vocab:bootstrap/primitives.factor" run-file
-> load-help? off { "resource:core" } vocab-roots set [
~quotation~ % "math.integers" require
"math.floats" require "memory" require
"io.streams.c" require "vocabs.loader" require
"syntax" require "bootstrap.layouts" require
~quotation~ %
] [ ] make bootstrap-startup-quot set
]
(U)
Quotation: [
"Creating primitives and basic runtime structures..." print
flush H{ } clone sub-primitives set
"vocab:bootstrap/syntax.factor" parse-file architecture get
{ ~array~ ~array~ ~array~ ~array~ ~array~ ~array~ } ?at
[ "Bad architecture: " prepend throw ] unless
-> "vocab:cpu/" "/bootstrap.factor" surround
parse-file "vocab:bootstrap/layouts/layouts.factor"
parse-file "syntax" lookup-vocab vocab-words
bootstrap-syntax set H{ } clone dictionary set
H{ } clone root-cache set H{ } clone source-files set
H{ } clone update-map set H{ } clone implementors-map set
init-caches bootstrapping? on ( -- ) call-effect
( -- ) call-effect "accessors" create-vocab drop
num-types get f builtins set [
( -- ) call-effect ~array~ ~quotation~ each
"fixnum" "math" create register-builtin
"bignum" "math" create register-builtin
"tuple" "kernel" create register-builtin
"float" "math" create register-builtin
"f" "syntax" lookup-word register-builtin
"array" "arrays" create register-builtin
"wrapper" "kernel" create register-builtin
"callstack" "kernel" create register-builtin
"string" "strings" create register-builtin
"quotation" "quotations" create register-builtin
"dll" "alien" create register-builtin
"alien" "alien" create register-builtin
"word" "words" create register-builtin
"byte-array" "byte-arrays" create register-builtin
"f" "syntax" lookup-word ~array~ define-builtin
"f" "syntax" create
~quotation~ "predicate" set-word-prop
"f?" "syntax" vocab-words delete-at
"t" "syntax" lookup-word define-singleton-class
"c-ptr" "alien" create ~quotation~ ~array~ make
define-union-class
"array-capacity" "sequences.private" create
"fixnum" "math" lookup-word
~quotation~ ~quotation~ make define-predicate-class
"array-capacity" "sequences.private" lookup-word
~195 more~
] with-compilation-unit
]
(O)
Method: M\ object throw
(U)
Quotation: [
OBJ-CURRENT-THREAD special-object error-thread set-global
current-continuation -> error-continuation set-global
[ original-error set-global ] [ rethrow ] bi
]
Anyone have any ideas?
From: mclag...@hotmail.com
To: factor-talk@lists.sourceforge.net
Date: Fri, 10 Aug 2012 17:50:12 +
Subject
Re: [Factor-talk] Any way of making sense of what's in the boot image?
Typically the architecture is a combination of os and arch:
IN: scratchpad my-arch .
"unix-x86.64"
You can use the "my-arch" word to make an image for your architecture:
IN: scratchpad my-arch make-image
On Fri, Aug 10, 2012 at 1:56 PM, Michael Clagett wrote:
> Hi --
>
> I've been trying to run the make-image word from the Listener and got as
> far as this trace:
>
> IN: scratchpad Command: restart
> 1: Note:
> Added "bootstrap.image" vocabulary to search path
> "x86.32" make-image
> Loading resource:/core/bootstrap/stage1.factor
> Bootstrap stage 1...
> Loading vocab:bootstrap/primitives.factor
> Creating primitives and basic runtime structures...
> Loading vocab:bootstrap/syntax.factor
>
> From Traceback:
>
> Data Stack:
>
> [ ~quotation~ with-compilation-unit ]
> "Bad architecture: x86.32"
>
> Call Stack:
>
> (U)
> Quotation: [ set-namestack init-catchstack self quot>> call -> stop ]
> (O)
> Word: listener-thread
> (O)
> Word: listener
> (O)
> Word: (listener)
> (U)
> Quotation: [
> [ ~quotation~ dip swap ~quotation~ dip ] dip swap
> [ call datastack ] dip -> swap [ set-datastack ] dip
> ]
> (U)
> Quotation: [ call -> datastack ]
> (O)
> Word: make-image
> (U)
> Quotation: [
> "Bootstrap stage 1..." print
> flush "vocab:bootstrap/primitives.factor" run-file
> -> load-help? off { "resource:core" } vocab-roots set [
> ~quotation~ % "math.integers" require
> "math.floats" require "memory" require
> "io.streams.c" require "vocabs.loader" require
> "syntax" require "bootstrap.layouts" require
> ~quotation~ %
> ] [ ] make bootstrap-startup-quot set
> ]
> (U)
> Quotation: [
> "Creating primitives and basic runtime structures..." print
> flush H{ } clone sub-primitives set
> "vocab:bootstrap/syntax.factor" parse-file architecture get
> { ~array~ ~array~ ~array~ ~array~ ~array~ ~array~ } ?at
> [ "Bad architecture: " prepend throw ] unless
> -> "vocab:cpu/" "/bootstrap.factor" surround
> parse-file "vocab:bootstrap/layouts/layouts.factor"
> parse-file "syntax" lookup-vocab vocab-words
> bootstrap-syntax set H{ } clone dictionary set
> H{ } clone root-cache set H{ } clone source-files set
> H{ } clone update-map set H{ } clone implementors-map set
> init-caches bootstrapping? on ( -- ) call-effect
> ( -- ) call-effect "accessors" create-vocab drop
> num-types get f builtins set [
> ( -- ) call-effect ~array~ ~quotation~ each
> "fixnum" "math" create register-builtin
> "bignum" "math" create register-builtin
> "tuple" "kernel" create register-builtin
> "float" "math" create register-builtin
> "f" "syntax" lookup-word register-builtin
> "array" "arrays" create register-builtin
> "wrapper" "kernel" create register-builtin
> "callstack" "kernel" create register-builtin
> "string" "strings" create register-builtin
> "quotation" "quotations" create register-builtin
> "dll" "alien" create register-builtin
> "alien" "alien" create register-builtin
> "word" "words" create register-builtin
> "byte-array" "byte-arrays" create register-builtin
> "f" "syntax" lookup-word ~array~ define-builtin
> "f" "syntax" create
> ~quotation~ "predicate" set-word-prop
> "f?" "syntax" vocab-words delete-at
> "t" "syntax" lookup-word define-singleton-class
> "c-ptr" "alien" create ~quotation~ ~array~ make
> define-union-class
> "array-capacity" "sequences.private" create
> "fixnum" "math" lookup-word
> ~quotation~ ~quotation~ make define-predicate-class
> "array-capacity" "sequences.private" lookup-word
> ~195 more~
> ] with-compilation-unit
> ]
> (O)
> Method: M\ object throw
> (U)
> Quotation: [
> OBJ-CURRENT-THREAD special-object error-thread set-global
> current-continuation
Re: [Factor-talk] Any way of making sense of what's in the boot image?
Hi -- I've been trying to run the make-image word from the Listener and got as
far as this trace: IN: scratchpad Command: restart
1: Note:
Added "bootstrap.image" vocabulary to search path
"x86.32" make-image
Loading resource:/core/bootstrap/stage1.factor
Bootstrap stage 1...
Loading vocab:bootstrap/primitives.factor
Creating primitives and basic runtime structures...
Loading vocab:bootstrap/syntax.factor
From Traceback: Data Stack: [ ~quotation~ with-compilation-unit ]"Bad
architecture: x86.32" Call Stack: (U)
Quotation: [ set-namestack init-catchstack self quot>> call -> stop ]
(O)
Word: listener-thread
(O)
Word: listener
(O)
Word: (listener)
(U)
Quotation: [
[ ~quotation~ dip swap ~quotation~ dip ] dip swap
[ call datastack ] dip -> swap [ set-datastack ] dip
]
(U)
Quotation: [ call -> datastack ]
(O)
Word: make-image
(U)
Quotation: [
"Bootstrap stage 1..." print
flush "vocab:bootstrap/primitives.factor" run-file
-> load-help? off { "resource:core" } vocab-roots set [
~quotation~ % "math.integers" require
"math.floats" require "memory" require
"io.streams.c" require "vocabs.loader" require
"syntax" require "bootstrap.layouts" require
~quotation~ %
] [ ] make bootstrap-startup-quot set
]
(U)
Quotation: [
"Creating primitives and basic runtime structures..." print
flush H{ } clone sub-primitives set
"vocab:bootstrap/syntax.factor" parse-file architecture get
{ ~array~ ~array~ ~array~ ~array~ ~array~ ~array~ } ?at
[ "Bad architecture: " prepend throw ] unless
-> "vocab:cpu/" "/bootstrap.factor" surround
parse-file "vocab:bootstrap/layouts/layouts.factor"
parse-file "syntax" lookup-vocab vocab-words
bootstrap-syntax set H{ } clone dictionary set
H{ } clone root-cache set H{ } clone source-files set
H{ } clone update-map set H{ } clone implementors-map set
init-caches bootstrapping? on ( -- ) call-effect
( -- ) call-effect "accessors" create-vocab drop
num-types get f builtins set [
( -- ) call-effect ~array~ ~quotation~ each
"fixnum" "math" create register-builtin
"bignum" "math" create register-builtin
"tuple" "kernel" create register-builtin
"float" "math" create register-builtin
"f" "syntax" lookup-word register-builtin
"array" "arrays" create register-builtin
"wrapper" "kernel" create register-builtin
"callstack" "kernel" create register-builtin
"string" "strings" create register-builtin
"quotation" "quotations" create register-builtin
"dll" "alien" create register-builtin
"alien" "alien" create register-builtin
"word" "words" create register-builtin
"byte-array" "byte-arrays" create register-builtin
"f" "syntax" lookup-word ~array~ define-builtin
"f" "syntax" create
~quotation~ "predicate" set-word-prop
"f?" "syntax" vocab-words delete-at
"t" "syntax" lookup-word define-singleton-class
"c-ptr" "alien" create ~quotation~ ~array~ make
define-union-class
"array-capacity" "sequences.private" create
"fixnum" "math" lookup-word
~quotation~ ~quotation~ make define-predicate-class
"array-capacity" "sequences.private" lookup-word
~195 more~
] with-compilation-unit
]
(O)
Method: M\ object throw
(U)
Quotation: [
OBJ-CURRENT-THREAD special-object error-thread set-global
current-continuation -> error-continuation set-global
[ original-error set-global ] [ rethrow ] bi
]
Anyone have any ideas? From: mclag...@hotmail.com
To: factor-talk@lists.sourceforge.net
Date: Fri, 10 Aug 2012 17:50:12 +
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot image?
Thanks for the reference. I assume that will be helpful once I get past
stepping through the bootstrapping code and am in the Listener environment.
From: mrj...@gmail.com
Date: Fri, 10 Aug 2012 10:40:28 -0700
To: factor-talk@lists.sourceforge.net
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
image?
You might also find it useful to try the "Walker" which allows you to step
through Factor code:
http://docs.factorcode.org/content/article-ui-walker.html
Re: [Factor-talk] Any way of making sense of what's in the boot image?
Thanks for the reference. I assume that will be helpful once I get past stepping through the bootstrapping code and am in the Listener environment.From: mrj...@gmail.com Date: Fri, 10 Aug 2012 10:40:28 -0700 To: factor-talk@lists.sourceforge.net Subject: Re: [Factor-talk] Any way of making sense of what's in the boot image? You might also find it useful to try the "Walker" which allows you to step through Factor code: http://docs.factorcode.org/content/article-ui-walker.html On Fri, Aug 10, 2012 at 10:29 AM, Michael Clagett wrote: Not a problem any more. WinDbg does the trick just fine. It was just Visual Studio. From: mclag...@hotmail.com To: factor-talk@lists.sourceforge.net Date: Fri, 10 Aug 2012 11:51:00 +0000 Subject: Re: [Factor-talk] Any way of making sense of what's in the boot image? > > P.S. Incidentally, while I am on the subject, I find myself able to trace > > through the VM startup code in Visual Studio with no problem at all, until I > > get to the factor_vm::c_to_factor, which wraps a c-to-factor sub-primitive > > inside of a callback stub and then invokes that function. On both a Windows > > 7 platform and a Windows Server 2008 platform, my Visual Studio blows up > > when the callback address loaded into EDX is called. Anybody ever > > encountered this and any idea how to get around it? > > Factor code doesn't follow the C calling convention so it's unlikely > that a debugger will be able to walk a stack with Factor frames. In > recent versions of Factor you can trigger Factor's own low-level > debugger with ^C, which will let you backtrace and step through Factor > frames. > > -Joe > If I'm understanding this correctly, you are suggesting that if I'm in the Factor development environment, I can drop into Factor's own low-level debugger. But what do people do (you language maintainer, for example) when you need to debug the startup code that builds an image that needs to be in place for the development environment even to be launched? Am I correctly understanding you, that I can't use a Windows debugger to step through the init sequence, but don't have Factor's debugger available yet either? Or am I missing something? Any insights would be greatly appreciated. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Any way of making sense of what's in the boot image?
You might also find it useful to try the "Walker" which allows you to step through Factor code: http://docs.factorcode.org/content/article-ui-walker.html On Fri, Aug 10, 2012 at 10:29 AM, Michael Clagett wrote: > Not a problem any more. WinDbg does the trick just fine. It was just > Visual Studio. > > -- > From: mclag...@hotmail.com > To: factor-talk@lists.sourceforge.net > Date: Fri, 10 Aug 2012 11:51:00 +0000 > > Subject: Re: [Factor-talk] Any way of making sense of what's in the boot > image? > > > > > P.S. Incidentally, while I am on the subject, I find myself able to > trace > > > through the VM startup code in Visual Studio with no problem at all, > until I > > > get to the factor_vm::c_to_factor, which wraps a c-to-factor > sub-primitive > > > inside of a callback stub and then invokes that function. On both a > Windows > > > 7 platform and a Windows Server 2008 platform, my Visual Studio blows > up > > > when the callback address loaded into EDX is called. Anybody ever > > > encountered this and any idea how to get around it? > > > > Factor code doesn't follow the C calling convention so it's unlikely > > that a debugger will be able to walk a stack with Factor frames. In > > recent versions of Factor you can trigger Factor's own low-level > > debugger with ^C, which will let you backtrace and step through Factor > > frames. > > > > -Joe > > > > If I'm understanding this correctly, you are suggesting that if I'm in the > Factor development environment, I can drop into Factor's own low-level > debugger. But what do people do (you language maintainer, for example) > when you need to debug the startup code that builds an image that needs to > be in place for the development environment even to be launched? Am I > correctly understanding you, that I can't use a Windows debugger to step > through the init sequence, but don't have Factor's debugger available yet > either? Or am I missing something? > > Any insights would be greatly appreciated. > > -- > Live Security Virtual Conference Exclusive live event will cover all the > ways today's security and threat landscape has changed and how IT managers > can respond. Discussions will include endpoint security, mobile security > and the latest in malware threats. > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ Factor-talk mailing list > Factor-talk@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/factor-talk > > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > Factor-talk mailing list > Factor-talk@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/factor-talk > > -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Any way of making sense of what's in the boot image?
Not a problem any more. WinDbg does the trick just fine. It was just Visual Studio. From: mclag...@hotmail.com To: factor-talk@lists.sourceforge.net Date: Fri, 10 Aug 2012 11:51:00 + Subject: Re: [Factor-talk] Any way of making sense of what's in the boot image? > > P.S. Incidentally, while I am on the subject, I find myself able to trace > > through the VM startup code in Visual Studio with no problem at all, until I > > get to the factor_vm::c_to_factor, which wraps a c-to-factor sub-primitive > > inside of a callback stub and then invokes that function. On both a Windows > > 7 platform and a Windows Server 2008 platform, my Visual Studio blows up > > when the callback address loaded into EDX is called. Anybody ever > > encountered this and any idea how to get around it? > > Factor code doesn't follow the C calling convention so it's unlikely > that a debugger will be able to walk a stack with Factor frames. In > recent versions of Factor you can trigger Factor's own low-level > debugger with ^C, which will let you backtrace and step through Factor > frames. > > -Joe > If I'm understanding this correctly, you are suggesting that if I'm in the Factor development environment, I can drop into Factor's own low-level debugger. But what do people do (you language maintainer, for example) when you need to debug the startup code that builds an image that needs to be in place for the development environment even to be launched? Am I correctly understanding you, that I can't use a Windows debugger to step through the init sequence, but don't have Factor's debugger available yet either? Or am I missing something? Any insights would be greatly appreciated. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Any way of making sense of what's in the boot image?
> > P.S. Incidentally, while I am on the subject, I find myself able to trace > > through the VM startup code in Visual Studio with no problem at all, until I > > get to the factor_vm::c_to_factor, which wraps a c-to-factor sub-primitive > > inside of a callback stub and then invokes that function. On both a Windows > > 7 platform and a Windows Server 2008 platform, my Visual Studio blows up > > when the callback address loaded into EDX is called. Anybody ever > > encountered this and any idea how to get around it? > > Factor code doesn't follow the C calling convention so it's unlikely > that a debugger will be able to walk a stack with Factor frames. In > recent versions of Factor you can trigger Factor's own low-level > debugger with ^C, which will let you backtrace and step through Factor > frames. > > -Joe > If I'm understanding this correctly, you are suggesting that if I'm in the Factor development environment, I can drop into Factor's own low-level debugger. But what do people do (you language maintainer, for example) when you need to debug the startup code that builds an image that needs to be in place for the development environment even to be launched? Am I correctly understanding you, that I can't use a Windows debugger to step through the init sequence, but don't have Factor's debugger available yet either? Or am I missing something? Any insights would be greatly appreciated. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Any way of making sense of what's in the boot image?
Quick question about parse-file.Is the quotation that is returned on the stack as a result of this word a parse tree, as discussed in the documentation's article on parsing? This would be a parse tree as in "Tokens are appended to the parse tree, the top level of which is a quotation returned by the original parser invocation.", right? There could also potentially be nested elements in the tree contributed by other parse words encountered in the course of satisfying the original parser invocation. Am I understanding this correctly? Thanks. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Any way of making sense of what's in the boot image?
Much appreciated, thanks. I had actually already discovered some significant portion of what you explain below, which is why I'm going to hold off on the baby-step questions so that I can save the limited Joe Groff bandwidth that the universe is going to provide me for more meaty important stuff. > Date: Thu, 9 Aug 2012 06:26:54 -0700 > From: arc...@gmail.com > To: factor-talk@lists.sourceforge.net > Subject: Re: [Factor-talk] Any way of making sense of what's in the boot > image? > > On Wed, Aug 8, 2012 at 9:56 PM, Michael Clagett wrote: > > Hi Joe -- > > > > Thank you so much for your guidance. I'm assuming that it is the > > basis\bootstrap\image\image.factor and the core\bootstrap\primitives.factor, > > stage1.factor and syntax.factor that you are referring to? > > > > One question just to help me get oriented before I go into heavy > > head-twisting mode. I notice that all these files have significant numbers > > of pre-existing vocabularies that they use. If this is what is used to > > generate the early stage1 bootstrapping stuff, then am I correct to assume > > that this is done from some version of factor where all this stuff has built > > already from scratch (that would be the implication, if all these files are > > able to use those vocabularies)? Or is there some other mechanism at work > > here that I should know about, and if so, is it written up anywhere that you > > know about. > > > > I have just read Slava's January 2010 post on the bootstrapping mechanism, > > so I understand the mechanism a bit better now, but am still thinking there > > has to be some Factor system somewhere that was built without a bootstrap > > image in order to have the vocabularies available that are used to generate > > the bootstrapping. Is there anything anywhere documenting that aspect of > > the picture. The reason I ask is that I would like to get a sense of how > > extensive that core fundamental set of vocabularies is that is needed to > > process the primitives and stage1 factor files. > > > > Here's the USING statement for primitives.factor: > > > > USING: alien alien.strings arrays byte-arrays generic hashtables > > hashtables.private io io.encodings.ascii kernel math > > math.private math.order namespaces make parser sequences strings > > vectors words quotations assocs layouts classes classes.private > > classes.builtin classes.singleton classes.tuple > > classes.tuple.private kernel.private vocabs vocabs.loader > > source-files definitions slots classes.union > > classes.intersection classes.predicate compiler.units > > bootstrap.image.private io.files accessors combinators ; > > IN: bootstrap.primitives > > > > It's got a lot of stuff there. Is a lot of this built in the C++ code that > > constitutes the VM? Or is some fundamental processing capability put into > > place that allows the processing of factor files to build these > > vocabularies? And if so, is the factor source used also included in the > > downloaded platform? Or was this a special primordial code base that was > > used once and never really needed again? > > Although core/bootstrap/primitives.factor is in core/, it's not > actually loaded as-is into the boot image; it's really a script > designed to run as part of `make-image` in the host image. All of > those modules are loaded and run in the host image. While there of > course had to have been a primordial Factor that could boot itself, I > think it would be too different now to resemble current Factor. > Factor's bootstrapping loop evolved somewhat organically. > > You can tell whether a word is a C++ primitive by `see`ing it in the > listener. Primitive words show up as `PRIMITIVE:` when prettyprinted. > > At a high level, `make-image` has two stages: First, it executes > `core/bootstrap/stage1.factor`, which runs 'bootstrap/syntax.factor` > to transfer the basic syntax from the host image to the boot image, > `bootstrap/primitives.factor` to set up primitive words corresponding > to VM primitives, and a CPU-specific `basis/cpu/*/bootstrap.factor` > script to assemble "sub-primitives" which are blobs of assembly > language code composed by the VM's compiler. It also composes a > startup quotation to begin the second stage of bootstrap when the boot > image is started. Second, after the bootstrapping elements have been > loaded, it serializes the data structures loaded by the bootstrap > scripts into a boot image. Again, it does this without help from the > VM, though it does borrow some knowledge of layouts from the compiler > and
Re: [Factor-talk] Any way of making sense of what's in the boot image?
On Wed, Aug 8, 2012 at 9:56 PM, Michael Clagett wrote: > Hi Joe -- > > Thank you so much for your guidance. I'm assuming that it is the > basis\bootstrap\image\image.factor and the core\bootstrap\primitives.factor, > stage1.factor and syntax.factor that you are referring to? > > One question just to help me get oriented before I go into heavy > head-twisting mode. I notice that all these files have significant numbers > of pre-existing vocabularies that they use. If this is what is used to > generate the early stage1 bootstrapping stuff, then am I correct to assume > that this is done from some version of factor where all this stuff has built > already from scratch (that would be the implication, if all these files are > able to use those vocabularies)? Or is there some other mechanism at work > here that I should know about, and if so, is it written up anywhere that you > know about. > > I have just read Slava's January 2010 post on the bootstrapping mechanism, > so I understand the mechanism a bit better now, but am still thinking there > has to be some Factor system somewhere that was built without a bootstrap > image in order to have the vocabularies available that are used to generate > the bootstrapping. Is there anything anywhere documenting that aspect of > the picture. The reason I ask is that I would like to get a sense of how > extensive that core fundamental set of vocabularies is that is needed to > process the primitives and stage1 factor files. > > Here's the USING statement for primitives.factor: > > USING: alien alien.strings arrays byte-arrays generic hashtables > hashtables.private io io.encodings.ascii kernel math > math.private math.order namespaces make parser sequences strings > vectors words quotations assocs layouts classes classes.private > classes.builtin classes.singleton classes.tuple > classes.tuple.private kernel.private vocabs vocabs.loader > source-files definitions slots classes.union > classes.intersection classes.predicate compiler.units > bootstrap.image.private io.files accessors combinators ; > IN: bootstrap.primitives > > It's got a lot of stuff there. Is a lot of this built in the C++ code that > constitutes the VM? Or is some fundamental processing capability put into > place that allows the processing of factor files to build these > vocabularies? And if so, is the factor source used also included in the > downloaded platform? Or was this a special primordial code base that was > used once and never really needed again? Although core/bootstrap/primitives.factor is in core/, it's not actually loaded as-is into the boot image; it's really a script designed to run as part of `make-image` in the host image. All of those modules are loaded and run in the host image. While there of course had to have been a primordial Factor that could boot itself, I think it would be too different now to resemble current Factor. Factor's bootstrapping loop evolved somewhat organically. You can tell whether a word is a C++ primitive by `see`ing it in the listener. Primitive words show up as `PRIMITIVE:` when prettyprinted. At a high level, `make-image` has two stages: First, it executes `core/bootstrap/stage1.factor`, which runs 'bootstrap/syntax.factor` to transfer the basic syntax from the host image to the boot image, `bootstrap/primitives.factor` to set up primitive words corresponding to VM primitives, and a CPU-specific `basis/cpu/*/bootstrap.factor` script to assemble "sub-primitives" which are blobs of assembly language code composed by the VM's compiler. It also composes a startup quotation to begin the second stage of bootstrap when the boot image is started. Second, after the bootstrapping elements have been loaded, it serializes the data structures loaded by the bootstrap scripts into a boot image. Again, it does this without help from the VM, though it does borrow some knowledge of layouts from the compiler and other Factor libraries. > > P.S. Incidentally, while I am on the subject, I find myself able to trace > through the VM startup code in Visual Studio with no problem at all, until I > get to the factor_vm::c_to_factor, which wraps a c-to-factor sub-primitive > inside of a callback stub and then invokes that function. On both a Windows > 7 platform and a Windows Server 2008 platform, my Visual Studio blows up > when the callback address loaded into EDX is called. Anybody ever > encountered this and any idea how to get around it? Factor code doesn't follow the C calling convention so it's unlikely that a debugger will be able to walk a stack with Factor frames. In recent versions of Factor you can trigger Factor's own low-level debugger with ^C, which will let you backtrace and step through Factor frames. -Joe -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Di
Re: [Factor-talk] Any way of making sense of what's in the boot image?
Thank you, Joe, once again for your help. I have settled into a nice rythym of virtually tracing through the code by looking at the source (both vm and factor files), augmented by the Help system in the listener. That should keep me busy and out of your hair for a couple months (or couple years? :( ). Let me hold off on asking any more questions until I've had a chance to absorb some of this. Maybe one little question. Am I correct in suspecting that there is a high-level Factor word I can execute on demand and trace through the exectution of via the Factor debugger to get a more dynamic picture of how this all unfolds? Would it be make-image? Can you just call that directly or is it only called in the context of a sequence of operations that have already set other things up? > Date: Wed, 8 Aug 2012 21:12:23 -0700 > From: arc...@gmail.com > To: factor-talk@lists.sourceforge.net > Subject: Re: [Factor-talk] Any way of making sense of what's in the boot > image? > > On Wed, Aug 8, 2012 at 8:23 PM, Joe Groff wrote: > > > > The code in the bootstrap.image module outputs the bootstrap image as > > a binary blob. You can get a sense for the format of the bootstrap > > image and its contents by looking at that module. > > To clarify, by "output as a binary blob" I mean the code in > bootstrap.image doesn't have any special help from the VM—it just > generates a byte array whose contents resemble a Factor image and > outputs that to a file. It could be transliterated to another language > and still generate a valid boot image. > > -Joe > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > Factor-talk mailing list > Factor-talk@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/factor-talk -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Any way of making sense of what's in the boot image?
Hi Joe -- Thank you so much for your guidance. I'm assuming that it is the basis\bootstrap\image\image.factor and the core\bootstrap\primitives.factor, stage1.factor and syntax.factor that you are referring to? One question just to help me get oriented before I go into heavy head-twisting mode. I notice that all these files have significant numbers of pre-existing vocabularies that they use. If this is what is used to generate the early stage1 bootstrapping stuff, then am I correct to assume that this is done from some version of factor where all this stuff has built already from scratch (that would be the implication, if all these files are able to use those vocabularies)? Or is there some other mechanism at work here that I should know about, and if so, is it written up anywhere that you know about. I have just read Slava's January 2010 post on the bootstrapping mechanism, so I understand the mechanism a bit better now, but am still thinking there has to be some Factor system somewhere that was built without a bootstrap image in order to have the vocabularies available that are used to generate the bootstrapping. Is there anything anywhere documenting that aspect of the picture. The reason I ask is that I would like to get a sense of how extensive that core fundamental set of vocabularies is that is needed to process the primitives and stage1 factor files. Here's the USING statement for primitives.factor: USING: alien alien.strings arrays byte-arrays generic hashtables hashtables.private io io.encodings.ascii kernel math math.private math.order namespaces make parser sequences strings vectors words quotations assocs layouts classes classes.private classes.builtin classes.singleton classes.tuple classes.tuple.private kernel.private vocabs vocabs.loader source-files definitions slots classes.union classes.intersection classes.predicate compiler.units bootstrap.image.private io.files accessors combinators ; IN: bootstrap.primitives It's got a lot of stuff there. Is a lot of this built in the C++ code that constitutes the VM? Or is some fundamental processing capability put into place that allows the processing of factor files to build these vocabularies? And if so, is the factor source used also included in the downloaded platform? Or was this a special primordial code base that was used once and never really needed again? Any clarification you can provide (or better yet, any sources you can point me to that I can go and do the work to gain an understanding of this) would be greatly, greatly appreciated. I envision creating my own "Inside the Factor VM" and possibly "inside the Factor Compiler" writeup once I have accomplished what I am after. So hopefully I can give back a little after traveling up these respective learning curves. Thanks much. Mike P.S. Incidentally, while I am on the subject, I find myself able to trace through the VM startup code in Visual Studio with no problem at all, until I get to the factor_vm::c_to_factor, which wraps a c-to-factor sub-primitive inside of a callback stub and then invokes that function. On both a Windows 7 platform and a Windows Server 2008 platform, my Visual Studio blows up when the callback address loaded into EDX is called. Anybody ever encountered this and any idea how to get around it? Thanks.> Date: Wed, 8 Aug 2012 20:23:04 -0700 > From: arc...@gmail.com > To: factor-talk@lists.sourceforge.net > Subject: Re: [Factor-talk] Any way of making sense of what's in the boot > image? > > On Wed, Aug 8, 2012 at 3:24 PM, Michael Clagett wrote: > > Hi -- > > > > I've been tracing through the initial vm initialization code trying to get a > > picture of how Factor bootstraps itself. Does anyone know if there is a way > > to resolve code in the initial boot image that is being jit-compiled by > > factor_vm::prepare_boot_image to a set of symbolic names that can give a > > hint as to what functionality is included there? I'm trying to get a sense > > of the minimal functional set included here that allows higher-level initial > > code to be compiled. The comment on prepare_boot-image says "/* Compile > > code in boot image so that we can execute the startup quotation */". It > > would be nice to know what this code includes. My guess is that the answer > > is "no, there is no way" and that one just has to be in possession of > > whatever code generated it (and there's nothing to say that this was even a > > Factor system that did this in the first place; could have easily been some > > C++ code that just knew what bits to emit). > > > > But it never hurts to ask... > > > > Presumably if I proceed past this to a point where actual Factor code is > > being parsed and compiled, I
Re: [Factor-talk] Any way of making sense of what's in the boot image?
On Wed, Aug 8, 2012 at 8:23 PM, Joe Groff wrote: > > The code in the bootstrap.image module outputs the bootstrap image as > a binary blob. You can get a sense for the format of the bootstrap > image and its contents by looking at that module. To clarify, by "output as a binary blob" I mean the code in bootstrap.image doesn't have any special help from the VM—it just generates a byte array whose contents resemble a Factor image and outputs that to a file. It could be transliterated to another language and still generate a valid boot image. -Joe -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Any way of making sense of what's in the boot image?
On Wed, Aug 8, 2012 at 3:24 PM, Michael Clagett wrote: > Hi -- > > I've been tracing through the initial vm initialization code trying to get a > picture of how Factor bootstraps itself. Does anyone know if there is a way > to resolve code in the initial boot image that is being jit-compiled by > factor_vm::prepare_boot_image to a set of symbolic names that can give a > hint as to what functionality is included there? I'm trying to get a sense > of the minimal functional set included here that allows higher-level initial > code to be compiled. The comment on prepare_boot-image says "/* Compile > code in boot image so that we can execute the startup quotation */". It > would be nice to know what this code includes. My guess is that the answer > is "no, there is no way" and that one just has to be in possession of > whatever code generated it (and there's nothing to say that this was even a > Factor system that did this in the first place; could have easily been some > C++ code that just knew what bits to emit). > > But it never hurts to ask... > > Presumably if I proceed past this to a point where actual Factor code is > being parsed and compiled, I'll be able to get a feel for what primitives > are already being depended on? Or maybe not. Maybe it's just a "big bang" > where earlier word definitions can depend on later word definitions having > been initialized before they start their execution. Is mine a hopeless > effort? Would be nice to know before I suck up too much time with it. > > Thanks for any guidance anyone can provide. > > Regards, > > Mike The code in the bootstrap.image module outputs the bootstrap image as a binary blob. You can get a sense for the format of the bootstrap image and its contents by looking at that module. -Joe -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
