Eliot Miranda uploaded a new version of VMMaker to project VM Maker:
http://source.squeak.org/VMMaker/VMMaker.oscog-eem.3190.mcz
==================== Summary ====================
Name: VMMaker.oscog-eem.3190
Author: eem
Time: 14 June 2022, 5:31:11.343683 pm
UUID: 14a00f3f-f33e-49f5-a8d3-7021f5deccd5
Ancestors: VMMaker.oscog-eem.3189
findInterned: => lookup: now that findInterned: is deprecated.
=============== Diff against VMMaker.oscog-eem.3189 ===============
Item was changed:
----- Method: TMethod>>returnType: (in category 'accessing') -----
returnType: aString
"Set the type of the values returned by this method.
This string will be used in the C declaration of this function.
If the type exists as a symbol, use that."
returnType := aString isSymbol
ifTrue: [aString]
+ ifFalse: [(Symbol lookup: aString) ifNil: [aString]]!
- ifFalse: [(Symbol findInterned: aString) ifNil: [aString]]!
On 2022-06-14 06:37, Gerald Klix via Cuis-dev wrote:
> I did not ask a specific enough question:
> "Wasn't there a RiscV JIT VM? AFAIR Eliott wrote something about that
> one."
No. MIPS, ARM, and RISCV are all RISC architectures, and there is a
RiscOS which runs on ARM.
https://www.riscosopen.org/content/
Right now the image is running well, but I get an error
PNGReaderWriter crc error in chunk IHDR
But this does come up in the debugger! Not by crashing.
Probably an edge case with passing structs. Callouts and FFI need more
testing.
But, hey, celebrate success! Ran the first time I got everything to
compile. Wow! Bless the OpenSmalltalk crew! :)
Note that Allwinner D1 is a slow chip. One core. LicheeRV is finiky.
No graphics acceleration. Early days Debian Linux. You have to be
comfortable with Linux and SD cards to attempt it.
I wrote up basics at
https://github.com/KenDickey/opensmalltalk-vm-rv64/blob/Cog/building/linux6…
You probably want to read that first.
But, we are supposed to get fast, relatively cheap risc boards later
this year. Perhaps BeagleV? We have to be ready! ;^)
Good on ya,
-KenD
Hi,
I am trying to deploy CuisSmalltalk as a scripting language in Windows 10.
I am running the latest release of the VM
`Win32 built on Jun 2 2022 15:29:46 Compiler: Clang 14.0.3 [Production Spur 64-bit X64 VM]`.
I got almost all working but I found this little roadblock.
As far as I can say the "-headless" parameter is ignored in Windows 10.
---- demo, headless is ignored.
```
win cmd> C:\CUIS\squeak.cog.spur_win64x64\SqueakConsole.exe -headless C:\CUIS\Cuis6.0-5031.image
-d "StdIOWriteStream stdout nextPutAll: 'hello world'; newline."
-d "Smalltalk quit."
=> hello world [ headless is not working, if you remove the 'Smalltalk quit' you will see the window is well alive].
```
By comparison the parameter "-vm-display-null" works very well in Linux.
---- demo, fully working, windows ghost popping up as in Linux.
```
$> ./sqcogspur64linuxht/squeak -vm-display-null Cuis-Smalltalk-Dev/Cuis6.0-5031.image
-d "StdIOWriteStream stdout nextPutAll: 'Hello World'; newLine"
-d 'Smalltalk quit.'
=> Hello World [and goodbye]
```
bye
Nicola
--
Reply to this email directly or view it on GitHub:
https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/639
You are receiving this because you are subscribed to this thread.
Message ID: <OpenSmalltalk/opensmalltalk-vm/issues/639(a)github.com>
Greetings,
More work to do, but I got a $25 RISC development board (Sipeed Lichee
RV Dock) and got opensmalltalk-vm working with Cuis (Note truetype fonts
and vector graphics rotation).
Older vm version to update and debug to do, but basic
image/windows/tools work fine on real RISC-V RV64G hardware!
https://github.com/KenDickey/opensmalltalk-vm-rv64
FYI,
-KenD
Branch: refs/heads/Cog
Home: https://github.com/OpenSmalltalk/opensmalltalk-vm
Commit: 1964ef3daf588e1cd5e7a653b5c7a7bffba86ca2
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/1964ef3daf588e1cd5…
Author: Eliot Miranda <eliot.miranda(a)gmail.com>
Date: 2022-06-13 (Mon, 13 Jun 2022)
Changed paths:
M src/v3.cog/cointerp.c
M src/v3.cog/cointerp.h
M src/v3.cog/gcc3x-cointerp.c
M src/v3.stack/gcc3x-interp.c
M src/v3.stack/interp.c
Log Message:
-----------
CogVM sources as per VMMaker.oscog-eem.3189
Fix regression in building the v3 VMs caused by VMMaker.oscog-eem.3183.
[New]ObjectMemory (i.e. v3) must export storeLong32:ofObject:withValue:.
Branch: refs/heads/virtend
Home: https://github.com/OpenSmalltalk/opensmalltalk-vm
Commit: 3a9c70ee947534800fa4176fff3e0f1f6a8b7b26
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/3a9c70ee947534800f…
Author: Eliot Miranda <eliot.miranda(a)gmail.com>
Date: 2022-06-13 (Mon, 13 Jun 2022)
Changed paths:
M platforms/Cross/vm/sqVirtualMachine.c
M platforms/Cross/vm/sqVirtualMachine.h
M platforms/iOS/plugins/CameraPlugin/AVFoundationVideoGrabber.m
M src/spur64.cog/cogit.h
M src/spur64.cog/cogitARMv8.c
M src/spur64.cog/cogitX64SysV.c
M src/spur64.cog/cogitX64WIN64.c
M src/spur64.cog/cointerp.c
M src/spur64.cog/cointerp.h
M src/spur64.cog/cointerpmt.c
M src/spur64.cog/cointerpmt.h
M src/spur64.cog/gcc3x-cointerp.c
M src/spur64.cog/gcc3x-cointerpmt.c
Log Message:
-----------
Manually integrate rthe following commits for src/spur64.cog:
commit f4192577c954b8f8f010171396da6872345fb2b4
Author: Eliot Miranda <eliot.miranda(a)gmail.com>
Date: Mon Jun 13 18:28:39 2022 -0700
Eliminate a warning, and potential run-time crash, when asking to enable
camera access on macos.
commit ff5264234c2823207684d01cf78dddd7f39c24bb
Author: Eliot Miranda <eliot.miranda(a)gmail.com>
Date: Mon Jun 13 18:11:18 2022 -0700
CogVM source as per VMMaker.oscog-eem.3188
Refactor CoInterpreter>>#followForwardedFieldsInCurrentMethod to avoid the
(albeit rare) possibility of failing to reenable method zone executability after
a send fault. Move the pruneYoungReferrers into followForwardedLiteralsIn:
and use followForwardedLiteralsImplementationIn: within
followMovableLiteralsAndUpdateYoungReferrers instead of the refactored
followForwardedLiteralsIn:.
commit e9ceb5073084a8b3164235ac66882cf8e8e988ee
Author: Eliot Miranda <eliot.miranda(a)gmail.com>
Date: Thu Jun 9 12:31:03 2022 -0700
CogVM source as per VMMaker.oscog-eem.3187
Fix failure of Spur image segment loading due to not having enough memory to
allocate the Array of loaded objects result. This is unlikely, but can happen
with large image segments if memory is scarce. Fix received from Max Leske
with thanks.
A little less inlining does you good. Don't inline
allocateSlots:format:classIndex: in low-frequency primitives.
Improve some comments in the changed methods.