On Wed, Jan 29, 2014 at 12:14 PM, Jecel Assumpcao Jr. jecel@merlintec.comwrote:
Frank Shearar wrote:
A little bit of digging reveals this:
https://web.archive.org/web/20090122105548/http://talklikeaduck.denhaven2.co...
which looks like it was written by Rick DeNatale (judging by the "I served as the secretary of X3J20." sentence.)
Thanks for the information! I was aware of Smalltalk/X using dual bytecode sets but didn't know it had been done previously. Allowing multiple bytecodes is one of the features planned for Cog, right?
Cog already supports multiple bytecode sets. The current compiled method header format has only space for a single bit so Cog currently supprts two bytecode sets. The Squeak VMs support only the current Squeak V3 + closures bytecode set (see EncoderForV3PlusClosures).
Teh Newspeak VMs support that, extended with two bytecodes for the old Newspeak implementation, and a new bytecode set that I designed for Newspeak that supports absent receiver sends. It's very much a first cut and we may do more bytecode sets. In a Newspeak image look for EncoderForNewsqueakV4, and in the VMMaker package look for initializeBytecodeTableForNewspeakV4
My own design allows multiple bytecodes but it is very costly to switch between them.
Why is it costly?
In Cog it is essentially free in the JIT, and in the interpreter it is a matter of testing a flag on method activation and return and setting the bytecode set offset as a result. I'm grateful to Claus Gittinger for this technique.
So in the Cog Newspeak Interpreter the bytecode dispatch case statement has 512 entries, 256 for the Squeak V3 + Closures + Newspeak set, and 256 for the NewsqueakV4 set. The dispatch looks like
fetchNextBytecode "This method fetches the next instruction (bytecode). Each bytecode method is responsible for fetching the next bytecode, preferably as early as possible to allow the memory system time to process the request before the next dispatch."
self cppIf: MULTIPLEBYTECODESETS ifTrue: [currentBytecode := self fetchByte + bytecodeSetSelector] ifFalse: [currentBytecode := self fetchByte]
setMethod: aMethodObj "Set the method and determine the bytecode set based on the method header's sign. If MULTIPLEBYTECODESETS then a negative header selects the alternate bytecode set. Conditionalizing the code on MULTIPLEBYTECODESETS allows the header sign bit to be used for other experiments." <inline: true> method := aMethodObj. self assert: (objectMemory isOopCompiledMethod: method). self cppIf: MULTIPLEBYTECODESETS ifTrue: [bytecodeSetSelector := (self methodUsesAlternateBytecodeSet: method) ifTrue: [256] ifFalse: [0]]
where setMethod: is called on return, and its close twin setMethod:methodHeader: is called on frame build.
Eliot,
Cog already supports multiple bytecode sets. The current compiled method header format has only space for a single bit so Cog currently supprts two bytecode sets. [...]
Interesting. I don't know why, but I had an impression that the plan was to add an offset as some bits in each method header that you would then add to each "logical" bytecode to get the "physical" bytecode. I guess one bit is equivalent to having the offset be either 0 or 256. Allowing other values would make it possible to share bytecodes between sets (but with different values), but this would be too complicated for practical use.
Why is it costly?
The instruction ("microcode") cache has a 4KB area that is loaded by the hardware and a 4KB area that is loaded under software control. This second area is a table with 256 entries of 16 bytes each, with each entry holding the native code to interpret a particular bytecode. So to switch to another bytecode set you have to reload this 4KB area with different contents, and that will probably cause the rest of the cache to miss a lot for a while.
Adding a flag and either growing that part of the cache to 8KB or reducing each entry from 16 to 8 bytes each would allow two bytecode sets. But with several cores, each with its separate cache, this probably isn't worth it.
-- Jecel
To reverse a MorphicEvent into an primitive event I need to unmap the buttons and modifiers. In a primitive event, the fifth element (buttons) can be 1,2 or 4 and the sixth element (modifiers) 1,2,4 or 8.
HandMorph >> generateMouseEvent combines them into one field as such:
buttons := evtBuf fifth. modifiers := evtBuf sixth. buttons := buttons bitOr: (modifiers bitShift: 3).
I need to reverse that "buttons bitOr: (modifiers bitShift: 3)" back into the original values to recreate the primitive event. Here are the possible values of B(uttons) and M(odifiers) under that operation:
B M MAP 1 bitOr:(1 bitShift:3 ) 9 1 bitOr:(2 bitShift:3 ) 17 1 bitOr:(4 bitShift:3 ) 33 1 bitOr:(8 bitShift:3 ) 65
2 bitOr:(1 bitShift:3 ) 10 2 bitOr:(2 bitShift:3 ) 18 2 bitOr:(4 bitShift:3 ) 34 2 bitOr:(8 bitShift:3 ) 66
4 bitOr:(1 bitShift:3 ) 12 4 bitOr:(2 bitShift:3 ) 20 4 bitOr:(4 bitShift:3 ) 36 4 bitOr:(8 bitShift:3 ) 68
So, given a MAP on the right, I need to derive a B and a M.
I can figure something out, but it will probably be ugly. Hence, this email to the list. Any bit-fiddlers on the board who know an elegant method?
thx.
tty.
On Tue, Feb 11, 2014 at 06:05:30PM -0800, gettimothy wrote:
To reverse a MorphicEvent into an primitive event I need to unmap the buttons and modifiers. In a primitive event, the fifth element (buttons) can be 1,2 or 4 and the sixth element (modifiers) 1,2,4 or 8.
HandMorph >> generateMouseEvent combines them into one field as such:
buttons := evtBuf fifth. modifiers := evtBuf sixth. buttons := buttons bitOr: (modifiers bitShift: 3).I need to reverse that "buttons bitOr: (modifiers bitShift: 3)" back into the original values to recreate the primitive event. Here are the possible values of B(uttons) and M(odifiers) under that operation:
B M MAP 1 bitOr:(1 bitShift:3 ) 9 1 bitOr:(2 bitShift:3 ) 17 1 bitOr:(4 bitShift:3 ) 33 1 bitOr:(8 bitShift:3 ) 65
2 bitOr:(1 bitShift:3 ) 10 2 bitOr:(2 bitShift:3 ) 18 2 bitOr:(4 bitShift:3 ) 34 2 bitOr:(8 bitShift:3 ) 66
4 bitOr:(1 bitShift:3 ) 12 4 bitOr:(2 bitShift:3 ) 20 4 bitOr:(4 bitShift:3 ) 36 4 bitOr:(8 bitShift:3 ) 68
So, given a MAP on the right, I need to derive a B and a M.
I can figure something out, but it will probably be ugly. Hence, this email to the list. Any bit-fiddlers on the board who know an elegant method?
M is (MAP >> 3) and B is (MAP bitAnd: 7).
MAP M := MAP >> 3 B := MAP bitAnd: 7 9 1 1 17 2 1 33 4 1 65 8 1
10 1 2 18 2 2 34 4 2 66 8 2
12 1 4 20 2 4 36 4 4 68 8 4
Hello,
B= map bitAnd: 7.
M= map bitShift: -3.
All the best,
Ron Teitelbaum
From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of gettimothy Sent: Tuesday, February 11, 2014 9:06 PM To: The general-purpose Squeak developers list Subject: [squeak-dev] for the operation MAP := B bitOr:( M bitShift:3) given MAP how do I derive B and M?
To reverse a MorphicEvent into an primitive event I need to unmap the buttons and modifiers. In a primitive event, the fifth element (buttons) can be 1,2 or 4 and the sixth element (modifiers) 1,2,4 or 8.
HandMorph >> generateMouseEvent combines them into one field as such:
buttons := evtBuf fifth. modifiers := evtBuf sixth. buttons := buttons bitOr: (modifiers bitShift: 3).
I need to reverse that "buttons bitOr: (modifiers bitShift: 3)" back into the original values to recreate the primitive event. Here are the possible values of B(uttons) and M(odifiers) under that operation:
B M MAP 1 bitOr:(1 bitShift:3 ) 9 1 bitOr:(2 bitShift:3 ) 17 1 bitOr:(4 bitShift:3 ) 33 1 bitOr:(8 bitShift:3 ) 65
2 bitOr:(1 bitShift:3 ) 10 2 bitOr:(2 bitShift:3 ) 18 2 bitOr:(4 bitShift:3 ) 34 2 bitOr:(8 bitShift:3 ) 66
4 bitOr:(1 bitShift:3 ) 12 4 bitOr:(2 bitShift:3 ) 20 4 bitOr:(4 bitShift:3 ) 36 4 bitOr:(8 bitShift:3 ) 68
So, given a MAP on the right, I need to derive a B and a M.
I can figure something out, but it will probably be ugly. Hence, this email to the list. Any bit-fiddlers on the board who know an elegant method?
thx.
tty.
David and Ron.
Thank you.
Its been decades since I have done any bit manipulation and I froze up (:
The answer came to me last night when I half-asleep.
It is clear now what was going on. Somebody needed the data in one field, so they scooched the modifiers up to the next three bits and then tacked on the button.
To reverse this I need to unscooch and un-tack.
When I posted the question, I was looking at MAP and thinking, "Ok, its close to 64 that means its this, so do that" which is way off base.
Sorry for the noise; I am better now (:
humbly.
tty
---- On Tue, 11 Feb 2014 19:49:12 -0800 Ron Teitelbaum<ron@usmedrec.com> wrote ----
Hello,
B= map bitAnd: 7. M= map bitShift: -3.
All the best,
Ron Teitelbaum
From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of gettimothy Sent: Tuesday, February 11, 2014 9:06 PM To: The general-purpose Squeak developers list Subject: [squeak-dev] for the operation MAP := B bitOr:( M bitShift:3) given MAP how do I derive B and M?
To reverse a MorphicEvent into an primitive event I need to unmap the buttons and modifiers. In a primitive event, the fifth element (buttons) can be 1,2 or 4 and the sixth element (modifiers) 1,2,4 or 8.
HandMorph >> generateMouseEvent combines them into one field as such:
buttons := evtBuf fifth. modifiers := evtBuf sixth. buttons := buttons bitOr: (modifiers bitShift: 3).
I need to reverse that "buttons bitOr: (modifiers bitShift: 3)" back into the original values to recreate the primitive event. Here are the possible values of B(uttons) and M(odifiers) under that operation:
B M MAP 1 bitOr:(1 bitShift:3 ) 9 1 bitOr:(2 bitShift:3 ) 17 1 bitOr:(4 bitShift:3 ) 33 1 bitOr:(8 bitShift:3 ) 65
2 bitOr:(1 bitShift:3 ) 10 2 bitOr:(2 bitShift:3 ) 18 2 bitOr:(4 bitShift:3 ) 34 2 bitOr:(8 bitShift:3 ) 66
4 bitOr:(1 bitShift:3 ) 12 4 bitOr:(2 bitShift:3 ) 20 4 bitOr:(4 bitShift:3 ) 36 4 bitOr:(8 bitShift:3 ) 68
So, given a MAP on the right, I need to derive a B and a M.
I can figure something out, but it will probably be ugly. Hence, this email to the list. Any bit-fiddlers on the board who know an elegant method?
thx.
tty.
Yep. That is exactly right.
It’s all just 1’s and 0’s J
Ron
From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of gettimothy Sent: Wednesday, February 12, 2014 6:44 AM To: The general-purpose Squeak developers list Subject: RE: [squeak-dev] for the operation MAP := B bitOr:( M bitShift:3) given MAP how do I derive B and M?
David and Ron.
Thank you.
Its been decades since I have done any bit manipulation and I froze up (:
The answer came to me last night when I half-asleep.
It is clear now what was going on. Somebody needed the data in one field, so they scooched the modifiers up to the next three bits and then tacked on the button.
To reverse this I need to unscooch and un-tack.
When I posted the question, I was looking at MAP and thinking, "Ok, its close to 64 that means its this, so do that" which is way off base.
Sorry for the noise; I am better now (:
humbly.
tty
---- On Tue, 11 Feb 2014 19:49:12 -0800 Ron Teitelbaumron@usmedrec.com wrote ----
Hello,
B= map bitAnd: 7.
M= map bitShift: -3.
All the best,
Ron Teitelbaum
From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of gettimothy Sent: Tuesday, February 11, 2014 9:06 PM To: The general-purpose Squeak developers list Subject: [squeak-dev] for the operation MAP := B bitOr:( M bitShift:3) given MAP how do I derive B and M?
To reverse a MorphicEvent into an primitive event I need to unmap the buttons and modifiers. In a primitive event, the fifth element (buttons) can be 1,2 or 4 and the sixth element (modifiers) 1,2,4 or 8.
HandMorph >> generateMouseEvent combines them into one field as such:
buttons := evtBuf fifth. modifiers := evtBuf sixth. buttons := buttons bitOr: (modifiers bitShift: 3).
I need to reverse that "buttons bitOr: (modifiers bitShift: 3)" back into the original values to recreate the primitive event. Here are the possible values of B(uttons) and M(odifiers) under that operation:
B M MAP 1 bitOr:(1 bitShift:3 ) 9 1 bitOr:(2 bitShift:3 ) 17 1 bitOr:(4 bitShift:3 ) 33 1 bitOr:(8 bitShift:3 ) 65
2 bitOr:(1 bitShift:3 ) 10 2 bitOr:(2 bitShift:3 ) 18 2 bitOr:(4 bitShift:3 ) 34 2 bitOr:(8 bitShift:3 ) 66
4 bitOr:(1 bitShift:3 ) 12 4 bitOr:(2 bitShift:3 ) 20 4 bitOr:(4 bitShift:3 ) 36 4 bitOr:(8 bitShift:3 ) 68
So, given a MAP on the right, I need to derive a B and a M.
I can figure something out, but it will probably be ugly. Hence, this email to the list. Any bit-fiddlers on the board who know an elegant method?
thx.
tty.
On 12-02-2014, at 12:27 PM, Ron Teitelbaum ron@usmedrec.com wrote:
Yep. That is exactly right.
It’s all just 1’s and 0’s
Which is all well and good until you run out of 1’s, like we sometimes used to when I was a young’un trudging to school barefoot in the snow, uphill both ways.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Klingon Code Warrior:- 7) "You question the worthiness of my Code?! I should kill you where you stand!"
On Wed, Feb 12, 2014 at 8:58 PM, tim Rowledge tim@rowledge.org wrote:
On 12-02-2014, at 12:27 PM, Ron Teitelbaum ron@usmedrec.com wrote:
Yep. That is exactly right.
It's all just 1's and 0's
Which is all well and good until you run out of 1's, like we sometimes used to when I was a young'un trudging to school barefoot in the snow, uphill both ways.
Really? We always had so many 1s we ran out of storage. Reels and reels of nothing but 1s, and the tape drive smoking 'cause we were running it at double speed to try to keep up.
On 12-02-2014, at 6:08 PM, Colin Putney colin@wiresong.com wrote:
On Wed, Feb 12, 2014 at 8:58 PM, tim Rowledge tim@rowledge.org wrote:
On 12-02-2014, at 12:27 PM, Ron Teitelbaum ron@usmedrec.com wrote:
Yep. That is exactly right.
It’s all just 1’s and 0’s
Which is all well and good until you run out of 1’s, like we sometimes used to when I was a young’un trudging to school barefoot in the snow, uphill both ways.
Really? We always had so many 1s we ran out of storage. Reels and reels of nothing but 1s, and the tape drive smoking 'cause we were running it at double speed to try to keep up.
Oh come on; surely everyone knew how to renormalize and convert them all to halves ?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: RCM: Randomly Corrupt Microcode
tim Rowledge
On 12-02-2014, at 12:27 PM, Ron Teitelbaum ron@usmedrec.com wrote:
Yep. That is exactly right.
Its all just 1s and 0s
Which is all well and good until you run out of 1s, like we sometimes
used to
when I was a youngun trudging to school barefoot
You had FEET?
in the snow, uphill both ways.
tim
On Wed, Feb 12, 2014 at 7:23 PM, Ron Teitelbaum ron@usmedrec.com wrote:
tim Rowledge
On 12-02-2014, at 12:27 PM, Ron Teitelbaum ron@usmedrec.com wrote:
Yep. That is exactly right.
It's all just 1's and 0's
Which is all well and good until you run out of 1's, like we sometimes
used to
when I was a young'un trudging to school barefoot
You had FEET?
yes, but there was only the one pair to share between all 17 siblings...
in the snow, uphill both ways.
tim
Tim Rowledge observed:
Which is all well and good until you run out of 1's, like we sometimes used to when I was a young'un trudging to school barefoot in the snow, uphill both ways.
Ron Teitelbaum exclaimed:
You had FEET?
Eliot Miranda clarified:
yes, but there was only the one pair to share between all 17 siblings...
You guys are being silly, but when I was in the first year of the university I actualy kept a bag full of 1s. The computer was a Burroughs B6700 and students had to use punched cards to program it (this was replaced with terminals the following year). While on normal days the both the card reader/printer room and the keypunch room were deserted, on the due dates for student projects the lines were Disney-level long. To have a faster turn-around for small edits, I had previously collected a bag full of chad from the keypunch machine (the 1s), had typed a card with all characters to have a reference for the codes and had a razor blade for cutting new holes (the 0s). There was no need for tape or anything like that to keep the chad in the covered up holes as the card went through the reader: both the hole and the chad had rough borders and rubbing a fingernail on them on a smooth surface would expand them slightly.
-- Jecel p.s: the 1s and 0s in this story are probably inverted - just apply XOR 1 and it will be true
LOL!
Thanks for the support and laughs.
tty
---- On Wed, 12 Feb 2014 20:42:19 -0800 Eliot Miranda <eliot.miranda@gmail.com> wrote ----
On Wed, Feb 12, 2014 at 7:23 PM, Ron Teitelbaum <ron@usmedrec.com> wrote: > tim Rowledge > > > On 12-02-2014, at 12:27 PM, Ron Teitelbaum <ron@usmedrec.com> wrote: > > > Yep. That is exactly right. > > > > It’s all just 1’s and 0’s > > Which is all well and good until you run out of 1’s, like we sometimes used to > when I was a young’un trudging to school barefoot
You had FEET?
yes, but there was only the one pair to share between all 17 siblings...
>in the snow, uphill both > ways. > > > tim >
Jecel Assumpcao Jr.
Tim Rowledge observed:
Which is all well and good until you run out of 1's, like we sometimes used to when I was a young'un trudging to school barefoot in the snow, uphill both ways.
Ron Teitelbaum exclaimed:
You had FEET?
Eliot Miranda clarified:
yes, but there was only the one pair to share between all 17 siblings...
You guys are being silly, but when I was in the first year of the
university I
actualy kept a bag full of 1s. The computer was a Burroughs B6700 and students had to use punched cards to program it (this was
replaced
with terminals the following year). While on normal days the both the card reader/printer room and the keypunch room were deserted, on the due dates for student projects the lines were Disney-level long. To have a faster turn-around for small edits, I had previously collected a
bag full
of chad from the keypunch machine (the 1s), had typed a card with all
characters
to have a reference for the codes and had a razor blade for cutting new
holes
(the 0s). There was no need for tape or anything like that to keep the
chad in the
covered up holes as the card went through the reader: both the hole and
the
chad had rough borders and rubbing a fingernail on them on a smooth
surface
would expand them slightly.
That's pretty funny.
-- Jecel p.s: the 1s and 0s in this story are probably inverted - just apply XOR 1 and it will be true
Of course we have Bob Arnings' wonderful punched card morph at http://www.squeaksource.com/PunchedCards, so it sounds like we are going to need an enhancement to provide a ChadMorph and and ScotchTapeMorph now.
Dave
Jecel Assumpcao Jr.
Tim Rowledge observed:
Which is all well and good until you run out of 1's, like we sometimes used to when I was a young'un trudging to school barefoot in the snow, uphill both ways.
Ron Teitelbaum exclaimed:
You had FEET?
Eliot Miranda clarified:
yes, but there was only the one pair to share between all 17 siblings...
You guys are being silly, but when I was in the first year of the
university I
actualy kept a bag full of 1s. The computer was a Burroughs B6700 and students had to use punched cards to program it (this was
replaced
with terminals the following year). While on normal days the both the card reader/printer room and the keypunch room were deserted, on the due dates for student projects the lines were Disney-level long. To have a faster turn-around for small edits, I had previously collected a
bag full
of chad from the keypunch machine (the 1s), had typed a card with all
characters
to have a reference for the codes and had a razor blade for cutting new
holes
(the 0s). There was no need for tape or anything like that to keep the
chad in the
covered up holes as the card went through the reader: both the hole and
the
chad had rough borders and rubbing a fingernail on them on a smooth
surface
would expand them slightly.
That's pretty funny.
-- Jecel p.s: the 1s and 0s in this story are probably inverted - just apply XOR 1 and it will be true
Hi tim,
Which is all well and good until you run out of 1s, like we sometimes used to when I was a youngun trudging to school barefoot in the snow, uphill both ways.
I think we went to the same school. We are having one of those snow storms right now here in New Jersey.
Lou ----------------------------------------------------------- Louis LaBrunda Keystone Software Corp. SkypeMe callto://PhotonDemon mailto:Lou@Keystone-Software.com http://www.Keystone-Software.com
squeak-dev@lists.squeakfoundation.org
-
Colin Putney -
David T. Lewis -
Eliot Miranda -
gettimothy -
Jecel Assumpcao Jr. -
Louis LaBrunda -
Ron Teitelbaum -
tim Rowledge