Menu
▾
▴
powermops-beta
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(13) |
Dec
(37) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(8) |
Feb
(9) |
Mar
(3) |
Apr
(15) |
May
(67) |
Jun
(65) |
Jul
(39) |
Aug
(37) |
Sep
(17) |
Oct
(48) |
Nov
(50) |
Dec
(8) |
| 2007 |
Jan
(78) |
Feb
(11) |
Mar
(37) |
Apr
(82) |
May
(21) |
Jun
(60) |
Jul
(68) |
Aug
(30) |
Sep
(22) |
Oct
(31) |
Nov
(84) |
Dec
(33) |
| 2008 |
Jan
(11) |
Feb
(10) |
Mar
(59) |
Apr
(8) |
May
(9) |
Jun
(26) |
Jul
(25) |
Aug
(8) |
Sep
|
Oct
(4) |
Nov
|
Dec
(3) |
| 2009 |
Jan
|
Feb
|
Mar
(17) |
Apr
(2) |
May
(5) |
Jun
(11) |
Jul
(57) |
Aug
(22) |
Sep
(20) |
Oct
(14) |
Nov
(1) |
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
(1) |
Sep
(23) |
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
(14) |
Feb
(3) |
Mar
|
Apr
(6) |
May
|
Jun
|
Jul
(3) |
Aug
(31) |
Sep
(17) |
Oct
(15) |
Nov
(20) |
Dec
(13) |
| 2012 |
Jan
(14) |
Feb
(4) |
Mar
|
Apr
|
May
(3) |
Jun
(1) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
(1) |
May
(3) |
Jun
(1) |
Jul
|
Aug
|
Sep
(1) |
Oct
(6) |
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
(5) |
Apr
(26) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(8) |
Dec
(2) |
| 2017 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(5) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2018 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(5) |
| 2019 |
Jan
(2) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
(1) |
Nov
(2) |
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(2) |
Aug
(2) |
Sep
(2) |
Oct
(2) |
Nov
(4) |
Dec
(1) |
| 2021 |
Jan
(3) |
Feb
(2) |
Mar
(2) |
Apr
(1) |
May
(5) |
Jun
(4) |
Jul
(1) |
Aug
(5) |
Sep
(4) |
Oct
(4) |
Nov
(1) |
Dec
(1) |
| 2022 |
Jan
(4) |
Feb
(4) |
Mar
(2) |
Apr
(1) |
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
(2) |
Oct
|
Nov
(1) |
Dec
(1) |
| 2023 |
Jan
(1) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(3) |
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Michael H. <mic...@gm...> - 2025-07-30 20:59:42
|
Hi all, assuming anyone is still reading this. I'm going to ramble on anyway. My thoughts on LLVM from Oct 2023 went nowhere, since I started looking at Zig, and found that while it uses LLVM as a backend, there's a future plan to ditch it as it's too big. So I decided that was a rabbit-hole I didn't want to go down. So I went on with other things (if you're interested, look up mike_hore in britmodeller.com <http://britmodeller.com/>. That's me. Anyway I've been thinking about MAX. I was planning a minor revision to simplify it a bit, by only having one scalar register set and cutting back the object-oriented stuff somewhat, which I now think was a bit of overkill. But something else came up. I've always found the Burroughs large machines (and successors) wonderfully elegant, if a bit heavily slanted to Algol or other languages with nested blocks (not C). Anyway, there's been an argument (see Wikipedia) that as cumputer hardware has evolved, stack machines are just as fast and efficient as register-based machines, with denser code. The point is that in the 1990s and early 2000s it was a win to have the compiler allocate registers with lots of optimization and not get the hardware to do it. But that stopped being true 20 years ago. We started getting register renaming, result forwarding etc etc which basically meant that the old RISC model wasn't good enough any more. The hardware could do a better job assigning registers on the fly, and or course this could be optimized for whatever hardware complexity you were aiming at. So, where this is going, is I'm thinking of doing a Stack-based MAX. This will be SMAX. There's a lot to think about, but with all those MAX test cases, it will be a good opportunity to compare the resulting code and see if it is really all that much denser. I'm not planning a simple-minded compilation of stack-based Forth to SMAX, but rather keep all the MAX optimizations. It should stay basically the same right through to register allocation, which of course will be completely different. Don't expect anything soon. There are those Britmodeller projects waithing. Cheers, Mike. |
|
From: Michael H. <mic...@gm...> - 2024-12-08 06:17:03
|
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">That’s all right Nao, I couldn’t find any better words either. I couldn’t have done it without you. Anyway now we can get on with what’s next in our lives.<div><br></div><div>— Mike.</div><div><br></div><div><br></div><div><div dir="ltr">Sent from my iPad</div><div dir="ltr"><br><blockquote type="cite">On 8 Dec 2024, at 10:21 am, 櫻田直弘 <n.s...@gm...> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="auto">Thank you very much, Mike.<div dir="auto">I tried to find some better words. But I couldn't find any one.</div><div dir="auto">Thank you.</div><div dir="auto">Sincerely</div><div dir="auto">Nao Sacrada</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">2024年12月5日(木) 6:23 Michael Hore <<a href="mailto:mic...@gm...">mic...@gm...</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space">Hi all,<div><br></div><div>Well the easy bit first. My email address is now <a href="mailto:mic...@gm..." target="_blank" rel="noreferrer">mic...@gm...</a> -- I have had this address for a long time as a backup, but my old address - <a href="mailto:mik...@aa..." target="_blank" rel="noreferrer">mik...@aa...</a> has now gone away because the new owners wanted to start charging. Not a lot, but the whole idea of charging for an email service when gmail and hotmail are around, is frankly ridiculous.</div><div><br></div><div>Now my main reason for writing. It's time for me to formally end my involvement with the whole Mops project. There are a number of reasons. The first is that Apple currently seems to have no interest in producing a 27 inch iMac with an ARM chip (Apple silicon). I love my desktop iMac with its big screen, but it seems I'm stuck with Intel. So I have no way to progress work on an ARM version of Mops.</div><div><br></div><div>But the main reason is that Mops just doesn't represent the state of the art in system-level programming any more. Object orientation has fallen out of favor as unnecessarily complex. With hindsight multiple inheritance wasn't worth the complexities of implementation and simply wasn't such a good idea. </div><div><br></div><div>Serious scientific programming now uses languages like Python, which is very easy for non-programmers, and the serious number-crunching is down in the libraries. <span style="color:rgb(0,0,0)"> For low-level system-type programming we now have languages such as Rust, and more recently Zig which is very lean and mean and easy to learn. Both these languages use LLVM for code generation which means they can produce very optimized code for any platform. They also have structs and methods, so they have picked up the good parts of object-oriented programming without calling it that.</span></div><div><br></div><div>So in future I'll probably use Zig if I want to do any low-level programming. I'm also involved in the AdaptIt project (<a href="http://adapt-it.org" target="_blank" rel="noreferrer">adapt-it.org</a>) which helps native speakers of one language adapt a Bible translation into another related language, where the speaker knows both languages. This is written in C++ which I guess isn't going away for a while. I've also used AdaptIt to adapt from Wubuy to Anindilyakwa (yes, I have other things going on in my life... I'm now 80 but still ridiculously healthy. and I'd just like to get my Parkrun time for the 5k down to 40 minutes...)</div><div><br></div><div>So finally, thanks to all the many collaborators who've helped over the years - since 1986 would you believe. Especially to Nao Sacrada who I got to meet in person last year. You've all done a great job.</div><div><br></div><div><br></div><div>All the best,</div><div>Mike.</div><div><br></div><div>(Mike Hore <a href="mailto:mic...@gm..." target="_blank" rel="noreferrer">mic...@gm...</a>)</div><div><br></div><div><br></div><div><br></div></div>_______________________________________________<br> PowerMops-BETA mailing list<br> <a href="mailto:Pow...@li..." target="_blank" rel="noreferrer">Pow...@li...</a><br> <a href="https://lists.sourceforge.net/lists/listinfo/powermops-beta" rel="noreferrer noreferrer" target="_blank">https://lists.sourceforge.net/lists/listinfo/powermops-beta</a><br> </blockquote></div> <span>_______________________________________________</span><br><span>PowerMops-BETA mailing list</span><br><span>Pow...@li...</span><br><span>https://lists.sourceforge.net/lists/listinfo/powermops-beta</span><br></div></blockquote></div></body></html> |
|
From: 櫻田直弘 <n.s...@gm...> - 2024-12-08 00:51:45
|
Thank you very much, Mike. I tried to find some better words. But I couldn't find any one. Thank you. Sincerely Nao Sacrada 2024年12月5日(木) 6:23 Michael Hore <mic...@gm...>: > Hi all, > > Well the easy bit first. My email address is now mic...@gm... > -- I have had this address for a long time as a backup, but my old address > - mik...@aa... has now gone away because the new owners wanted > to start charging. Not a lot, but the whole idea of charging for an email > service when gmail and hotmail are around, is frankly ridiculous. > > Now my main reason for writing. It's time for me to formally end my > involvement with the whole Mops project. There are a number of reasons. > The first is that Apple currently seems to have no interest in producing a > 27 inch iMac with an ARM chip (Apple silicon). I love my desktop iMac with > its big screen, but it seems I'm stuck with Intel. So I have no way to > progress work on an ARM version of Mops. > > But the main reason is that Mops just doesn't represent the state of the > art in system-level programming any more. Object orientation has fallen > out of favor as unnecessarily complex. With hindsight multiple inheritance > wasn't worth the complexities of implementation and simply wasn't such a > good idea. > > Serious scientific programming now uses languages like Python, which is > very easy for non-programmers, and the serious number-crunching is down in > the libraries. For low-level system-type programming we now have > languages such as Rust, and more recently Zig which is very lean and mean > and easy to learn. Both these languages use LLVM for code generation which > means they can produce very optimized code for any platform. They also > have structs and methods, so they have picked up the good parts of > object-oriented programming without calling it that. > > So in future I'll probably use Zig if I want to do any low-level > programming. I'm also involved in the AdaptIt project (adapt-it.org) > which helps native speakers of one language adapt a Bible translation into > another related language, where the speaker knows both languages. This is > written in C++ which I guess isn't going away for a while. I've also used > AdaptIt to adapt from Wubuy to Anindilyakwa (yes, I have other things going > on in my life... I'm now 80 but still ridiculously healthy. and I'd just > like to get my Parkrun time for the 5k down to 40 minutes...) > > So finally, thanks to all the many collaborators who've helped over the > years - since 1986 would you believe. Especially to Nao Sacrada who I got > to meet in person last year. You've all done a great job. > > > All the best, > Mike. > > (Mike Hore mic...@gm...) > > > > _______________________________________________ > PowerMops-BETA mailing list > Pow...@li... > https://lists.sourceforge.net/lists/listinfo/powermops-beta > |
|
From: Michael H. <mic...@gm...> - 2024-12-04 21:23:06
|
Hi all, Well the easy bit first. My email address is now mic...@gm... <mailto:mic...@gm...> -- I have had this address for a long time as a backup, but my old address - mik...@aa... <mailto:mik...@aa...> has now gone away because the new owners wanted to start charging. Not a lot, but the whole idea of charging for an email service when gmail and hotmail are around, is frankly ridiculous. Now my main reason for writing. It's time for me to formally end my involvement with the whole Mops project. There are a number of reasons. The first is that Apple currently seems to have no interest in producing a 27 inch iMac with an ARM chip (Apple silicon). I love my desktop iMac with its big screen, but it seems I'm stuck with Intel. So I have no way to progress work on an ARM version of Mops. But the main reason is that Mops just doesn't represent the state of the art in system-level programming any more. Object orientation has fallen out of favor as unnecessarily complex. With hindsight multiple inheritance wasn't worth the complexities of implementation and simply wasn't such a good idea. Serious scientific programming now uses languages like Python, which is very easy for non-programmers, and the serious number-crunching is down in the libraries. For low-level system-type programming we now have languages such as Rust, and more recently Zig which is very lean and mean and easy to learn. Both these languages use LLVM for code generation which means they can produce very optimized code for any platform. They also have structs and methods, so they have picked up the good parts of object-oriented programming without calling it that. So in future I'll probably use Zig if I want to do any low-level programming. I'm also involved in the AdaptIt project (adapt-it.org <http://adapt-it.org/>) which helps native speakers of one language adapt a Bible translation into another related language, where the speaker knows both languages. This is written in C++ which I guess isn't going away for a while. I've also used AdaptIt to adapt from Wubuy to Anindilyakwa (yes, I have other things going on in my life... I'm now 80 but still ridiculously healthy. and I'd just like to get my Parkrun time for the 5k down to 40 minutes...) So finally, thanks to all the many collaborators who've helped over the years - since 1986 would you believe. Especially to Nao Sacrada who I got to meet in person last year. You've all done a great job. All the best, Mike. (Mike Hore mic...@gm... <mailto:mic...@gm...>) |
|
From: Mike H. <mik...@aa...> - 2023-10-29 23:51:17
|
Hi all. I've been looking at LLVM, which is rapidly becoming the go-to basis for compiler writing on the Mac at least (and maybe even Windows). https://llvm.org/ Basically it's an intermediate language for compilation. It looks like a RISC machine with an indefinite number of registers, and all instructions are in SSA form (static single assignment) where each instruction generating a result assigns to one register which is then never changed. If you've looked at my MAX or Arm code generator you'll see that my node array is basically in SSA form. It's a very convenient form for optimization. All the latest Mac compilers such as Clang and Rust, generate LLVM code. LLVM can do a huge range of optimizations, and a compiler can choose which optimizations to use, and in what order. All the standard stuff like common subexpression elimination (CSE), dead code elimination, hoisting loop-invariant calculations out of loops, etc etc etc, can all be done at this level, and LLVM supports all these and many more. It's way more than any single individual could ever do. Then at code-generation time, a backend does register allocation and code generation in either binary or assembly for the chosen target. Now here's the list of currently supported targets - I'm not joking here... aarch64 - AArch64 (little endian) aarch64_32 - AArch64 (little endian ILP32) aarch64_be - AArch64 (big endian) amdgcn - AMD GCN GPUs arm - ARM arm64 - ARM64 (little endian) arm64_32 - ARM64 (little endian ILP32) armeb - ARM (big endian) avr - Atmel AVR Microcontroller bpf - BPF (host endian) bpfeb - BPF (big endian) bpfel - BPF (little endian) hexagon - Hexagon lanai - Lanai loongarch32 - 32-bit LoongArch loongarch64 - 64-bit LoongArch m68k - Motorola 68000 family mips - MIPS (32-bit big endian) mips64 - MIPS (64-bit big endian) mips64el - MIPS (64-bit little endian) mipsel - MIPS (32-bit little endian) msp430 - MSP430 [experimental] nvptx - NVIDIA PTX 32-bit nvptx64 - NVIDIA PTX 64-bit ppc32 - PowerPC 32 ppc32le - PowerPC 32 LE ppc64 - PowerPC 64 ppc64le - PowerPC 64 LE r600 - AMD GPUs HD2XXX-HD6XXX riscv32 - 32-bit RISC-V riscv64 - 64-bit RISC-V sparc - Sparc sparcel - Sparc LE sparcv9 - Sparc V9 systemz - SystemZ thumb - Thumb thumbeb - Thumb (big endian) ve - VE wasm32 - WebAssembly 32-bit wasm64 - WebAssembly 64-bit x86 - 32-bit X86: Pentium-Pro and above x86-64 - 64-bit X86: EM64T and AMD64 xcore - XCore xtensa - Xtensa 32 As I said, these backends alll do register allocation and code generation, and all the source code is open and included from the LLVM installation. So I've been able to write a silly little program and print out assembly for X86, AArch64 (Apple Silicon), PowerPC, and even IBM z/Architecture. It all Just Works. So why didn't we use LLVM for Mops? Well, for a start, LLVM is all written in C++ and all calls to it have to use C++. The internal format could change, and the published interface is through C++ calls. Second, when I was doing PowerMops LLVM didn't exist, and when we did iMops it was still very experimental. Third, space. A full install of LLVM is about a gigabyte. Now this includes all those backends, so if you only include the backend you want, you can get down to about 100 Mb. On Linux LLVM can be pre-installed, but on the Mac it's not, and would have to be bundled with the compiler. Our current iMops executable is just onder ONE MEGABYTE. So there's huge discrepancy here. But, still, a lot of water has gone under the bridge. Do people care much about space any more? We now have RAM in the order of terabytes. Maybe we're trying to solve a problem that doesn't exist any more. Anyway I'm going to try to learn Rust and also more about LLVM. That should keep me out of trouble for a while :-) Cheers, Mike. ------------------------------------------------------ Mike Hore mik...@aa... ------------------------------------------------------ |
|
From: Mike H. <mik...@aa...> - 2023-04-24 00:56:27
|
Hi all, https://sourceforge.net/projects/powermops/files/aMops-CG/aMops34.zip/download This version fixes a few small bugs, and as promised, now implements the late-bind cache. The details are all in the release notes. Cheers, Mike. ------------------------------------------------------ Mike Hore mik...@aa... ------------------------------------------------------ |
|
From: Mike H. <mik...@aa...> - 2023-01-03 06:24:27
|
https://sourceforge.net/projects/powermops/files/MAX/MAX61.zip/download As promised, this version reimplements multitasking and garbage collection. I now regard MAX as essentially complete, so I plan to take a break from it. There are some minor details still not implemented, but these are, well, minor, so I won't be doing anything about them any time soon. In the meantime, we're planning on TWO cruises in the first half of the year - including a trip to Japan where I hope to meet up with Nao at last!! Happy New Year everyone! -- Mike. ------------------------------------------------------ Mike Hore mik...@aa... ------------------------------------------------------ |
|
From: Mike H. <mik...@aa...> - 2022-12-07 22:53:41
|
https://sourceforge.net/projects/powermops/files/MAX/MAX60.zip/download As promised I've taken some time to look at the Morello project, which will possibly eventually add capabilities to Arm. This is done in a slightly different way to what we've been doing in MAX, so this version is the result of some rethinking. GPRs now have only one tag bit, and it's stored separately, so that GPRs containing binary data (not a capability/codeword) have a full 128 bits available for data. This has had a knock-on effect on a few instructions. Now it seems "capability" has become the standard term, where I've been using "codeword". So I've made this change throughout. Overall the running hasn't changed significantly, except that Multitasking and garbage collection are back on hold since they need updating for the new tagging scheme. They'll be back in the next version. Have a great Christmas or whatever your festive occasion is! Cheers, Mike. ------------------------------------------------------ Mike Hore mik...@aa... ------------------------------------------------------ |
|
From: Mike H. <mik...@aa...> - 2022-11-04 06:58:44
|
Hi all. https://sourceforge.net/projects/powermops/files/aMops-CG/aMops33.zip/download This one fixes the minor bug I mentioned a while back. It also has initial support for Morello, which isn't here yet but may be coming in future. All the details are in the Release Notes. Cheers, Mike. ------------------------------------------------------ Mike Hore mik...@aa... ------------------------------------------------------ |
|
From: Mike H. <mik...@aa...> - 2022-09-23 02:59:13
|
Hi all. https://sourceforge.net/projects/powermops/files/MAX/MAX52.zip/download Now I know the doco says "October 2022" but it was ready early, so here it is. The big thing this time is the re-implementation of multitasking, and now the addition of garbage collection. Actually it was easier than I thought. So now I want to have a break from MAX and go back to aMops. I should be able to get garbage collection in/ Also I want to have a good look at the Morello project which is planned to add capabilities to Arm. These are basically the same as what I've been calling "codewords" in MAX. I think the aim of this project is to investigate the possibility of adding capabilities (with capability registers) to Arm, to make it more secure against malware. Capabilities are basically glorified pointers, which are protected against improper manipulation. I think it's a great idea - well MAX has had them for quite a while now. So I'm thinking, future Arm chips in a couple of years' time will probably have capabilities incorporated, and we'll be ready. I'll add the new registers to the aMops emulator and update the code generator so we can exploit the hardware down the track. Cheers, Mike. ------------------------------------------------------ Mike Hore mik...@aa... ------------------------------------------------------ |
|
From: Mike H. <mik...@aa...> - 2022-09-04 01:54:50
|
https://sourceforge.net/projects/powermops/files/MAX/MAX51.zip/download This version now has most of the class/object stuff implemented - or re-implemented actually. I've been able to simplify things a bit. I've found a few bugs, but they were MAX-specific and don't apply to aMops. There's still only one outstanding bug I know about in aMops, and I already have a fix planned. Cheers, Mike. ------------------------------------------------------ Mike Hore mik...@aa... ------------------------------------------------------ |
|
From: Mike H. <mik...@aa...> - 2022-07-23 04:13:27
|
PS. Now I notice there's a project called Morello, which is aimed at bringing capabilities to Arm. (Google it)
If you've been following the MAX stuff you'll realize that capabilities (codewords) are what I've been going on about for years. Maybe at last the world is catching up... :-)
(But John Iliffe was there first.)
Cheers.
------------------------------------------------------
Mike Hore mik...@aa...
------------------------------------------------------
> On 23 Jul 2022, at 9:16 am, Mike Hore <mik...@aa...> wrote:
>
> Hi all,
>
> https://sourceforge.net/projects/powermops/files/MAX/MAX50.zip/download <https://sourceforge.net/projects/powermops/files/MAX/MAX50.zip/download>
>
>
> Well with my part of the aMops project mainly done for now, I went back to MAX. It might seem that there's not much point, but I enjoy it. Also, more importantly, the compiler is almost the same as the aMops compiler/code generator, so if bugs show up they're probably in aMops as well. And yes, I've found one already which I'll fix in the next aMops release.
>
> This version is quite a major change, since I've rolled in a number of good ideas from Arm, and re-jigged the opcodes. So there are a few things that didn't make it into this release - the class/object stuff, sparse vectors and multitasking. The code is all there, but needs updating for the new version. I'll do it for the next release. The OO stuff is important, since that will be the only way to access memory in MAX. Everything is an object.
>
> Anyway, till next time,
>
> Cheers, Mike.
>
>
> ------------------------------------------------------
> Mike Hore mik...@aa... <mailto:mik...@aa...>
> ------------------------------------------------------
>
> _______________________________________________
> PowerMops-BETA mailing list
> Pow...@li...
> https://lists.sourceforge.net/lists/listinfo/powermops-beta
|
|
From: Mike H. <mik...@aa...> - 2022-07-23 00:08:39
|
Hi all, https://sourceforge.net/projects/powermops/files/MAX/MAX50.zip/download <https://sourceforge.net/projects/powermops/files/MAX/MAX50.zip/download> Well with my part of the aMops project mainly done for now, I went back to MAX. It might seem that there's not much point, but I enjoy it. Also, more importantly, the compiler is almost the same as the aMops compiler/code generator, so if bugs show up they're probably in aMops as well. And yes, I've found one already which I'll fix in the next aMops release. This version is quite a major change, since I've rolled in a number of good ideas from Arm, and re-jigged the opcodes. So there are a few things that didn't make it into this release - the class/object stuff, sparse vectors and multitasking. The code is all there, but needs updating for the new version. I'll do it for the next release. The OO stuff is important, since that will be the only way to access memory in MAX. Everything is an object. Anyway, till next time, Cheers, Mike. ------------------------------------------------------ Mike Hore mik...@aa... <mailto:mik...@aa...> ------------------------------------------------------ |
|
From: Mike H. <mik...@aa...> - 2022-04-01 22:40:03
|
https://sourceforge.net/projects/powermops/files/aMops-CG/aMops-32.zip/download Hi all. The only change in this version, is that late binding is implemented. See the Release Notes. This is the basic implementation. For better performance, there should also be a late-bind cache as in PowerMops and iMops. I will probably add this and do another release eventually, though it's not a high priority right now. Cheers, Mike. ------------------------------------------------------ Mike Hore mik...@aa... ------------------------------------------------------ |
|
From: Mike H. <mik...@aa...> - 2022-03-02 19:13:40
|
Wow! That’s encouraging. We must have a lot of silent users who don’t come on the mailing list but just get stuff done. I hope aMops will continue to keep them happy. Cheers, Mike. ( currently in drizzly London) Sent from my iPad > On 2 Mar 2022, at 2:07 am, Jim Tittsler <ji...@on...> wrote: > PowerMops qualified for the SourceForge Community Choice badge (10,000 total downloads). I've added the badge to the front page of the website. > > > _______________________________________________ > PowerMops-BETA mailing list > Pow...@li... > https://lists.sourceforge.net/lists/listinfo/powermops-beta |
|
From: Jim T. <ji...@on...> - 2022-03-02 02:04:02
|
PowerMops qualified for the SourceForge Community Choice badge (10,000 total downloads). I've added the badge to the front page of the website. |
|
From: Mike H. <mik...@aa...> - 2022-02-19 02:26:24
|
Hi all,
Yes, I think all the main problems are now fixed. There's quite a list but I'm putting it all in the Release Notes.
There are now just a few tiny glitches which aren't show-stoppers, so I'm planning release for next weekend.
It can now compile itself and then under emulation, compile a simple definition. Realistically, more bugs will come up
- I'm reminded of the mythical many-headed Hydra where however many heads you chopped off, more kept appearing...
Anyway, it's probably at a point where Nao can take over and start to put in all the system interface stuff. The emulator
should allow some of this to be tested, though I guess the main job will have to wait until he and I have real hardware.
For my part I'm hanging out for the 27" M1 models which aren't out yet. Not that I'd be able to afford one :-)
(we've just relocated to a bigger place and until our old place sells, we're very tight on $$$ :-)
Anyway on Tuesday week we're off to the UK for 3 weeks. I'll be happy to forget computers for a while and instead think
of how cold I am (I live in the tropics, remember).
When we get back, I might do some more work on MAX which I really like - and there's no pressure for results. The Arm
work has given me lots of good ideas which I'd like to put in. The new dictionary, for a start.
Anyway, I'll send another message next weekend when everything's ready.
Cheers, Mike.
------------------------------------------------------
Mike Hore mik...@aa...
------------------------------------------------------
|
|
From: Mike H. <mik...@aa...> - 2022-02-19 02:26:22
|
Hi all,
Yes, I think all the main problems are now fixed. There's quite a list but I'm putting it all in the Release Notes.
There are now just a few tiny glitches which aren't show-stoppers, so I'm planning release for next weekend.
It can now compile itself and then under emulation, compile a simple definition. Realistically, more bugs will come up
- I'm reminded of the mythical many-headed Hydra where however many heads you chopped off, more kept appearing...
Anyway, it's probably at a point where Nao can take over and start to put in all the system interface stuff. The emulator
should allow some of this to be tested, though I guess the main job will have to wait until he and I have real hardware.
For my part I'm hanging out for the 27" M1 models which aren't out yet. Not that I'd be able to afford one :-)
(we've just relocated to a bigger place and until our old place sells, we're very tight on $$$ :-)
Anyway on Tuesday week we're off to the UK for 3 weeks. I'll be happy to forget computers for a while and instead think
of how cold I am (I live in the tropics, remember).
When we get back, I might do some more work on MAX which I really like - and there's no pressure for results. The Arm
work has given me lots of good ideas which I'd like to put in. The new dictionary, for a start.
Anyway, I'll send another message next weekend when everything's ready.
Cheers, Mike.
------------------------------------------------------
Mike Hore mik...@aa...
------------------------------------------------------
|
|
From: Mike H. <mik...@aa...> - 2022-02-09 01:20:20
|
Hi all,
It's been a few weeks, but there's progress.
You'll have seen that Nao has released a new iMops that works properly under OSX Monterey. Thanks Nao.
The big problem I've had, was that I hit a logical error that's probably been there for some time, and was probably in PowerMops. I had a fairly complex mechanism
under which, if a definition needed another stack operand partway through, it could add it to the list of input operands for the definition and pretend that it had been
there all the time. The problem, which is pretty obvious when you think about it, is that this is only valid in the first basic block of a definition. After that, we might
be in a conditional section or a loop or anything.
Where this had bitten me was that in running my new Arm code generator under emulation, a long way through the run, the data stack was underflowing. This
was causing random system exceptions when my code tried to store operands to illegal locations. Once I put a stack check into the emulator, I caught it right away.
The fix for all this is simple enough, and simplifies quite a bit of logic. In a later basic block, if I need an extra operand, I just pull it off the memory part of the stack.
Now of course this meant that the regression tests don't all work. Some other bugs got uncovered, and I'm still sorting out problems with the recursive tests like Ackermann.
I should get through all this - it's not over-complicated. But it has slowed things down a bit. I'm still hoping to get a new release out before we head to the UK in
3 weeks time, and this could be just about the final release. That would be very nice if it all works out.
Anyway, we'll be in the UK for 3 weeks - I've never been there, although Beth has. She has a cousin there who we'll be catching up with.
(By the way, we've now both had the dreaded Covid Omicron, and fully recovered. For me it was just a sniffle and sore throat for a few days. It was a bit worse for Beth.
But I'd hate to think what it would have been like if we hadn't been triple vaccinated!)
Cheers, Mike.
------------------------------------------------------
Mike Hore mik...@aa...
------------------------------------------------------
|
|
From: Nao S. <n.s...@gm...> - 2022-02-05 06:50:10
|
Hi All, (Excuse me for the double post with PowerMops Users ML) iMops 2.23 has been released from the SourceForge site: <https://sourceforge.net/projects/powermops/files/iMops/> file: iMops223.zip Crash on launching on Monterey (macOS 12) and other many glitches have been fixed. iMops is now a third party application without any developer signature. In order to avoid possible GateKeeper troubles, see file “Read Before Launching iMops or iBucket” in the distribution. enjoy! -Nao Sacrada |
|
From: Mike H. <mik...@aa...> - 2022-01-13 23:06:05
|
Thanks Jim - much appreciated.
-- Mike.
------------------------------------------------------
Mike Hore mik...@aa...
------------------------------------------------------
> On 13 Jan 2022, at 3:20 pm, Jim Tittsler <ji...@on...> wrote:
>
> In the hope of getting a little more public exposure, I've added the Readme and Release Notes to the web site.
> https://www.powermops.org/
>
> (The release notes are run through Pandoc to convert from RTF to a more web-friendly Markdown, run through a crude script to remove some debris from that conversion, and then hand massaged a bit. Eventually the script will need to take care of that last bit as well to make this process sustainable.)
>
>
> _______________________________________________
> PowerMops-BETA mailing list
> Pow...@li...
> https://lists.sourceforge.net/lists/listinfo/powermops-beta
|
|
From: Jim T. <ji...@on...> - 2022-01-13 06:16:09
|
In the hope of getting a little more public exposure, I've added the Readme and Release Notes to the web site. https://www.powermops.org/ (The release notes are run through Pandoc to convert from RTF to a more web-friendly Markdown, run through a crude script to remove some debris from that conversion, and then hand massaged a bit. Eventually the script will need to take care of that last bit as well to make this process sustainable.) |
|
From: Mike H. <mik...@aa...> - 2022-01-11 22:44:07
|
Hi all. I'm back from holidays :-) The new major version number isn't all that significant. This version can load itself, and begin to compile a little test definition up to reading the semicolon and set up the nodes (internal representation). I've also fixed the issues I mentioned for the previous version, and of course found a few others. See the Release nodes for all the details. https://sourceforge.net/projects/powermops/files/aMops-CG/aMops-30.zip/download Cheers, Mike. ------------------------------------------------------ Mike Hore mik...@aa... ------------------------------------------------------ |
|
From: Mike H. <mik...@aa...> - 2022-01-03 00:02:18
|
Hi all,
This is an immediate crash on launch. I've sent the crash report to Nao, and hopefully he can fix it.
In the meantime, if you have real work depending on iMops, all I can suggest is, don't update to Monterey.
Sorry, but this is Nao's area, and I haven't heard back from him yet.
Have a good New Year, and make sure you're vaccinated!!
-- Mike.
------------------------------------------------------
Mike Hore mik...@aa...
------------------------------------------------------
|
|
From: Mike H. <mik...@aa...> - 2021-12-06 23:43:33
|
Just a bit of an update before we go away for a few weeks.
The issue I mentioned here about the bytestrings Dictionary, Instructions and Global_data is a bit trickier than I
thought. I've been able to update the Arm versions of these bytestrings so they continue to use the existing
data which we've been adding into these objects during target compilation.
However I've found that there are a few places in the running Arm code (under emulation of course) where I'm
assuming that these bytestrings are now fixed, and won't move any more. This is fine for the regression tests, but
once we're emulating the code generator itself, then very obviously we CAN add data to these bytestrings, so they
can move.
This shouldn't be too hard to fix, but I'm out of time. We're heading down to Victoria for a family wedding and
birthday then staying for Christmas. While we're away I'll have a think about this problem and should have a fix
ready to apply when we get back just before New Year.
In the meantime, have a great Christmas all!!
Cheers, Mike.
------------------------------------------------------
Mike Hore mik...@aa...
------------------------------------------------------
> On 17 Nov 2021, at 9:49 am, Mike Hore <mik...@aa...> wrote:
>
>
>
> https://sourceforge.net/projects/powermops/files/aMops-CG/aMops-26.zip/download <https://sourceforge.net/projects/powermops/files/aMops-CG/aMops-26.zip/download>
>
>
> Hi all.
>
> I think I'm nearly at the end of the road, until we have real Arm hardware to run on.
>
> This version can start to compile a definition under emulation, up to the point where it needs to make a new dictionary entry for the new definition.
>
> The remaining issue isn't very major. The target-compiled code generator has its own copies of Dictionary, Instructions and Global_data - however
> we should continue using the existing versions of these objects since they are already using our new Arm data formats. So later I will provide a
> mechanism to import data into an object from an iMops object of the same class. This will be needed before we can continue compiling a definition
> under emulation.
>
> We will now be away on two different trips, since Australia is opening up after the COVID lockdowns. As part of this we'll be away for Christmas.
>
> So best wishes everyone, and especially to Nao looking at the system interface stuff!
>
> Cheers, Mike.
>
>
> ------------------------------------------------------
> Mike Hore mik...@aa... <mailto:mik...@aa...>
> ------------------------------------------------------
>
> _______________________________________________
> PowerMops-USERS mailing list
> Pow...@li...
> https://lists.sourceforge.net/lists/listinfo/powermops-users
|
39 messages has been excluded from this view by a project administrator.
