Hi,
I downloaded an ran the All-in-one and wanted to put it through its paces on Windows 7 32-bit. (I recognize 32-bit is a dying breed, but nonetheless...)
Test steps:
* ran squeak.bat * skipped configuration * ran update (to #18160) * ran Installer ensureRecentMetacello * ran:
Metacello new baseline: 'Seaside3'; repository: 'github://SeasideSt/Seaside:master/repository'; load
Please note: my notes below are from my initial run and have not been verified by duplicating my initial run.
results:
* initial fetches of BaselineOf* via Metacello all seem to initially stall, then retry, then succeed. My internet connection is pretty fast (gigabit fiber). In Transcript, each shows similar to:
...RETRY->BaselineOfSeaside3 ...RETRY->BaselineOfGrease
* the VM opened a Debug Console. Its text:
LoadLibrary(UUIDPlugin) (998: Invalid access to memory location.
)
LoadLibrary(UUIDPlugin.dll) (998: Invalid access to memory location.
)
UUIDPlugin was mentioned on the mailing list about two years ago, but I don't know if this is related.
* Grease throws various Undeclared warnings in the transcript; I wonder if it will need some adjustments for Squeak 5.2, or what. Some examples:
BlockContext>>fixCallbackTemps (home is Undeclared) BlockContext>>tempVarRefs(method is shadowed) BlockContext>>tempVarRefs (home is Undeclared) BlockContext>>tempVarRefs (startpc is Undeclared)
I decided to run some tests. Results:
* Grease tests all pass, though one prompts for author initials.
* KernelTests: 1 error, 1 unexpected pass.
passed: FloatTest>>#testTimesTwoPowerGradualUnderflow
failed: AllocationTest>>#testOutOfMemorySignal
(failed: #vmParameterAt:put: ... primitive 254) ?
* NetworkTests: all green
* "Tests-*" -- excepting Tests-Bugs, Tests-Release, DecompilerTests*
I interrupted & restarted these tests partway thru in order to deselect DecompilerTests. Hopefully that didn't affect my results, but is worth mentioning.
14 failures:
MCWorkingCopyTest>>#testDoubleRepeatedMerge MCWorkingCopyTest>>#testRedundantMerge MCWorkingCopyTest>>#testSnapshotAndLoad PackageDependencyTest>>#testEtoys PackageDependencyTest>>#testMorphic PackageDependencyTest>>#testMorphicExtras PackageDependencyTest>>#testNetwork PackageDependencyTest>>#testSUnitGUI PackageDependencyTest>>#testSound PackageDependencyTest>>#testSystem PackageDependencyTest>>#testTools UserInterfaceThemeTest>>#test01ImplementationHooks UserInterfaceThemeTest>>#test05ClearProperty UserInterfaceThemeTest>>#test06SetAndClearUnkownProperty
2 errors:
MCWorkingCopyRenameTest>>#testRenamePrefix MCWorkingCopyRenameTest>>#testRenameSuffix
* SqueakSSLTests -- all green!
* WebClientTests -- two failures:
WebClientServerTest>>#testLogging200 WebClientServerTest>>#testLogging404
* ChronologyTests -- one failure (maybe this is an expected failure)
DateAndTimeLeapTest>>#testAsSeconds
Thanks everybody, Tim
Hi Tim,
thanks for this. I don't want to respond to the tests per se, but I do want to address one parenthetical you make.
On Sat, Jul 28, 2018 at 1:27 PM, Tim Johnson digit@sonic.net wrote:
Hi,
I downloaded an ran the All-in-one and wanted to put it through its paces on Windows 7 32-bit. (I recognize 32-bit is a dying breed, but nonetheless...)
I don't think it is, at least not unless underlying OSs cease to support it. Because Smalltalk has infinite precision arithmetic the 32-bit system works very well for anything that doesn't require a huge address space. Because in a symbolic processing application the 32-bit implementation will move half the data than the 64-bit implementation, the 32-bit version should be faster, and so if the application fits within the 32-bit heap there's no reason to go to 64-bits; one is simply wasting memory bandwidth. I no longer use the 32-bit system with any regularity, but that's because the VM simulator is faster on 64-bits than on 32-bits because it spends a lot of time accessing the array (actually a Bitmap or DoubleWordArray) that contains the heap, and on 64-bits there's much less overflow into boxed integers. But in this case the application is to a symbolic processing one, but a low level bit manipulation one.
So I, and others, hope that the 32-bit system will live for a long time. The 64-bit version has its place, and in an increasing number of contexts it is required, but it can be overkill, and so there are string benefits to maintaining both. Especially since in Smalltalk we have the infrastructure to freely exchange code between the two and are much less dependent on word size than programs written in many other programming languages.
Test steps:
- ran squeak.bat
- skipped configuration
- ran update (to #18160)
- ran Installer ensureRecentMetacello
- ran:
Metacello new baseline: 'Seaside3'; repository: 'github://SeasideSt/Seaside:master/repository'; load
Please note: my notes below are from my initial run and have not been verified by duplicating my initial run.
results:
- initial fetches of BaselineOf* via Metacello all seem to initially
stall, then retry, then succeed. My internet connection is pretty fast (gigabit fiber). In Transcript, each shows similar to:
...RETRY->BaselineOfSeaside3 ...RETRY->BaselineOfGrease
- the VM opened a Debug Console. Its text:
LoadLibrary(UUIDPlugin) (998: Invalid access to memory location.
)
LoadLibrary(UUIDPlugin.dll) (998: Invalid access to memory location.
)
UUIDPlugin was mentioned on the mailing list about two years ago, but I don't know if this is related.
- Grease throws various Undeclared warnings in the transcript; I wonder
if it will need some adjustments for Squeak 5.2, or what. Some examples:
BlockContext>>fixCallbackTemps (home is Undeclared) BlockContext>>tempVarRefs(method is shadowed) BlockContext>>tempVarRefs (home is Undeclared) BlockContext>>tempVarRefs (startpc is Undeclared)
I decided to run some tests. Results:
Grease tests all pass, though one prompts for author initials.
KernelTests: 1 error, 1 unexpected pass.
passed: FloatTest>>#testTimesTwoPowerGradualUnderflow
failed: AllocationTest>>#testOutOfMemorySignal
(failed: #vmParameterAt:put: ... primitive 254) ?
NetworkTests: all green
"Tests-*" -- excepting Tests-Bugs, Tests-Release, DecompilerTests*
I interrupted & restarted these tests partway thru in order to deselect DecompilerTests. Hopefully that didn't affect my results, but is worth mentioning.
14 failures:
MCWorkingCopyTest>>#testDoubleRepeatedMerge MCWorkingCopyTest>>#testRedundantMerge MCWorkingCopyTest>>#testSnapshotAndLoad PackageDependencyTest>>#testEtoys PackageDependencyTest>>#testMorphic PackageDependencyTest>>#testMorphicExtras PackageDependencyTest>>#testNetwork PackageDependencyTest>>#testSUnitGUI PackageDependencyTest>>#testSound PackageDependencyTest>>#testSystem PackageDependencyTest>>#testTools UserInterfaceThemeTest>>#test01ImplementationHooks UserInterfaceThemeTest>>#test05ClearProperty UserInterfaceThemeTest>>#test06SetAndClearUnkownProperty
2 errors:
MCWorkingCopyRenameTest>>#testRenamePrefix MCWorkingCopyRenameTest>>#testRenameSuffix
SqueakSSLTests -- all green!
WebClientTests -- two failures:
WebClientServerTest>>#testLogging200 WebClientServerTest>>#testLogging404
- ChronologyTests -- one failure (maybe this is an expected failure)
DateAndTimeLeapTest>>#testAsSeconds
Thanks everybody, Tim
On 29 July 2018 at 05:55, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Tim,
thanks for this. I don't want to respond to the tests per se, but I dowant to address one parenthetical you make.
On Sat, Jul 28, 2018 at 1:27 PM, Tim Johnson digit@sonic.net wrote:
Hi,
I downloaded an ran the All-in-one and wanted to put it through its paces on Windows 7 32-bit. (I recognize 32-bit is a dying breed, but nonetheless...)
I don't think it is, at least not unless underlying OSs cease to support it. Because Smalltalk has infinite precision arithmetic the 32-bit system works very well for anything that doesn't require a huge address space. Because in a symbolic processing application the 32-bit implementation will move half the data than the 64-bit implementation, the 32-bit version should be faster, and so if the application fits within the 32-bit heap there's no reason to go to 64-bits; one is simply wasting memory bandwidth. I no longer use the 32-bit system with any regularity, but that's because the VM simulator is faster on 64-bits than on 32-bits because it spends a lot of time accessing the array (actually a Bitmap or DoubleWordArray) that contains the heap, and on 64-bits there's much less overflow into boxed integers. But in this case the application is to a symbolic processing one, but a low level bit manipulation one.
So I, and others, hope that the 32-bit system will live for a long time. The 64-bit version has its place, and in an increasing number of contexts it is required, but it can be overkill, and so there are string benefits to maintaining both. Especially since in Smalltalk we have the infrastructure to freely exchange code between the two and are much less dependent on word size than programs written in many other programming languages.
A particular case where this applies is Internet Of Things size devices.
cheers -ben
On Sat, Jul 28, 2018 at 5:25 PM, Ben Coman btc@openinworld.com wrote:
On 29 July 2018 at 05:55, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Tim,
thanks for this. I don't want to respond to the tests per se, but Ido
want to address one parenthetical you make.
On Sat, Jul 28, 2018 at 1:27 PM, Tim Johnson digit@sonic.net wrote:
Hi,
I downloaded an ran the All-in-one and wanted to put it through its
paces
on Windows 7 32-bit. (I recognize 32-bit is a dying breed, but nonetheless...)
I don't think it is, at least not unless underlying OSs cease to support
it.
Because Smalltalk has infinite precision arithmetic the 32-bit system
works
very well for anything that doesn't require a huge address space.
Because
in a symbolic processing application the 32-bit implementation will move half the data than the 64-bit implementation, the 32-bit version should
be
faster, and so if the application fits within the 32-bit heap there's no reason to go to 64-bits; one is simply wasting memory bandwidth. I no longer use the 32-bit system with any regularity, but that's because the
VM
simulator is faster on 64-bits than on 32-bits because it spends a lot of time accessing the array (actually a Bitmap or DoubleWordArray) that contains the heap, and on 64-bits there's much less overflow into boxed integers. But in this case the application is to a symbolic processing
one,
but a low level bit manipulation one.
So I, and others, hope that the 32-bit system will live for a long time. The 64-bit version has its place, and in an increasing number of
contexts it
is required, but it can be overkill, and so there are string benefits to maintaining both. Especially since in Smalltalk we have the
infrastructure
to freely exchange code between the two and are much less dependent on
word
size than programs written in many other programming languages.
A particular case where this applies is Internet Of Things size devices.
A 16-bit version would be killer. What 16-bit processors are doing well in the market these days, if any?
_,,,^..^,,,_ best, Eliot
On 29-07-2018, at 1:50 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
A particular case where this applies is Internet Of Things size devices.
A 16-bit version would be killer. What 16-bit processors are doing well in the market these days, if any?
I don't think there's any need for 16 bit; pretty much all IoT stuff is either ARM (with quite a lot of it using v8 cores because you might as well) or ESP/tensegrity. The ESP32 would run a stack vm ok I suspect, just needing a well trimmed image. The tiny ARM machines could potentially even run a Cog vm when memory allows.
The combination I think would have some value is 32bit oops for '64 bit' machines, ie using the better instruction sets. On ARM it would potentially make a big improvement to run AArch64 code but stay with 32 bit oops. You are of course somewhat at the mercy of your OS to be able to run within a 4Gb address space and not get silly.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Trying out for the javelin retrieval team.
Tim Rowledge wrote on Sun, 29 Jul 2018 14:20:11 -0700
On 29-07-2018, at 1:50 PM, Eliot Miranda wrote: A particular case where this applies is Internet Of Things size devices.
A 16-bit version would be killer. What 16-bit processors are doing well in the market these days, if any?
I think that the TI MSP430 is the most popular 16 bit processor.
https://en.wikipedia.org/wiki/TI_MSP430
I don't think there's any need for 16 bit; pretty much all IoT stuff is either ARM (with quite a lot of it using v8 cores because you might as well) or ESP/tensegrity. The ESP32 would run a stack vm ok I suspect, just needing a well trimmed image. The tiny ARM machines could potentially even run a Cog vm when memory allows.
If you have a chip with 512KB of RAM, running a 16 bit image would get you roughly the same results as a 32 bit image in 1MB (actually less since Strings and Bitmaps would not change size).
It is not a good idea to use a 16 bit processor to run a 16 bit image because 64KB (or 128KB with word addresses) is just not enough address space for Smalltalk. At the very least you need to be able to have multiple segments like in the 8086 or the Alto. But a 32 bit or even 64 bit processor can easily run a 16 bit Squeak as long as it can read and write 16 bit values from/to memory without being awkward.
In Alan's 1972 proposal for the dynabook he put in very little memory and expected to swap to tape in a virtual memory scheme (inspired by the LINC). So if your microcontroller only has 512KB of RAM but does have access to a serial Flash chip you could use that as a really fast tape and swap objects between the Flash and RAM as needed.
The combination I think would have some value is 32bit oops for '64 bit' machines, ie using the better instruction sets. On ARM it would potentially make a big improvement to run AArch64 code but stay with 32 bit oops. You are of course somewhat at the mercy of your OS to be able to run within a 4Gb address space and not get silly.
You could also use 32 bit oops and an object table to allow images larger than 4GB. Or you could have 32 bit oops that are addresses relative to some base and then the image would be less than 4GB but could be placed anywhere in the address space.
In any case, I did some work on 16 bit images and a key issue was not running out of oops. In my case I aliased SmallIntegers and Symbols and also merged all the methods in a class into a single object.
I have also worked on 8 bit Smalltalks (with objects divided into groups with at most 256 different oops in a group to local and remote objects) but that was a case of diminishing returns.
-- Jecel
On 1 August 2018 at 07:05, Jecel Assumpcao Jr. jecel@merlintec.com wrote:
Tim Rowledge wrote on Sun, 29 Jul 2018 14:20:11 -0700
On 29-07-2018, at 1:50 PM, Eliot Miranda wrote: A particular case where this applies is Internet Of Things size devices.
A 16-bit version would be killer. What 16-bit processors are doing well in the market these days, if any?
I think that the TI MSP430 is the most popular 16 bit processor.
From that page, maximum RAM seems to be 10K and max speed 25MHz.
Although here shows an $18 chip with 32KB of RAM. https://www.digikey.com.au/products/en/integrated-circuits-ics/embedded-micr...
Coincidentally I recently researched some ESP32 devices... https://www.mouser.com/Search/Refine.aspx?Keyword=esp32+rover $4.20 240MHz ESP32 WROVER 8MB SRAM, 4MB Flash $5.00 240MHz ESP32 WROVER 8MB SRAM, 16MB Flash (seems a new product, lead time 8 weeks)
Now I guess that most of the cheaper third-party (non-Espressif) boards use the WROOM that only have 512KB SRAM, but the extra SRAM of the WROVER will require less trimming of the Image. Background info on ESP32 Modules and Boards https://dl.espressif.com/doc/esp-idf/latest/hw-reference/modules-and-boards.... and further here http://esp-idf.readthedocs.io/en/latest/hw-reference/modules-and-boards.html
The ESP-WROVER-KIT V3 seems a useful host system for VM porting work. Useful features... 1. JTAG debugging interface may help VM development 2. MicroSD card slot for quickly switching between test systems and expanded memory 3. LCD screen might facilitate Morphic performance testing (although the aim would be for a headless system). Available approx US$50 at https://www.aliexpress.com/item/ESP-WROVER-KIT-ESP32-V3-Development-Board-wi... and https://www.adafruit.com/product/3384
I don't think there's any need for 16 bit; pretty much all IoT stuff is either ARM (with quite a lot of it using v8 cores because you might as well) or ESP/tensegrity. The ESP32 would run a stack vm ok I suspect, just needing a well trimmed image. The tiny ARM machines could potentially even run a Cog vm when memory allows.
If you have a chip with 512KB of RAM, running a 16 bit image would get you roughly the same results as a 32 bit image in 1MB (actually less since Strings and Bitmaps would not change size).
True, but memory keeps getting bigger and cheaper on all devices.
cheers -ben
squeak-dev@lists.squeakfoundation.org
-
Ben Coman -
Eliot Miranda -
Jecel Assumpcao Jr. -
Tim Johnson -
tim Rowledge