You can subscribe to this list here.
2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2006 |
Jan
(6) |
Feb
(5) |
Mar
(3) |
Apr
|
May
|
Jun
(17) |
Jul
(1) |
Aug
(6) |
Sep
|
Oct
|
Nov
|
Dec
|
2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(8) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(8) |
Oct
|
Nov
|
Dec
|
2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
(1) |
2012 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
(2) |
Dec
|
2013 |
Jan
(1) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2014 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
(1) |
2017 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
2018 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
(1) |
Nov
|
Dec
(3) |
2019 |
Jan
(1) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
(6) |
Aug
(1) |
Sep
|
Oct
|
Nov
(4) |
Dec
(1) |
2021 |
Jan
(3) |
Feb
|
Mar
(2) |
Apr
|
May
(1) |
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2022 |
Jan
(2) |
Feb
(2) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
2023 |
Jan
(1) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2024 |
Jan
|
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Doug H. <gli...@gm...> - 2010-09-15 09:06:07
|
If you use 'mword' instead of 'bl word' it seems to behave. Regards, -Doug : [defined] mword find nip 0<> ; : [undefined] mword find nip 0= ; On Sep 14, 2010, at 6:43 PM, Michael Morris wrote: > Okay, it looks like the bug is caused, yet again, by the new > optimizer, since it only shows up when you use FIND in a defined word. > Here's a revised test case: > > : [defined] bl word find nip 0<> ; > : [undefined] bl word find nip 0= ; > : no-op ; > > cr bl word no-op find . drop \ correctly prints -1 > cr bl word + find . drop \ also correctly prints -1 > > cr [defined] no-op . \ incorrectly prints 0 > cr [undefined] no-op . \ incorrectly prints -1 > cr [defined] + . \ correctly prints -1 > cr [undefined] + . \ correctly prints 0 > > Virtually, > Michael D. Morris > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > PowerMops-USERS mailing list > Pow...@li... > https://lists.sourceforge.net/lists/listinfo/powermops-users |
From: Michael M. <mor...@gm...> - 2010-09-14 22:43:09
|
Okay, it looks like the bug is caused, yet again, by the new optimizer, since it only shows up when you use FIND in a defined word. Here's a revised test case: : [defined] bl word find nip 0<> ; : [undefined] bl word find nip 0= ; : no-op ; cr bl word no-op find . drop \ correctly prints -1 cr bl word + find . drop \ also correctly prints -1 cr [defined] no-op . \ incorrectly prints 0 cr [undefined] no-op . \ incorrectly prints -1 cr [defined] + . \ correctly prints -1 cr [undefined] + . \ correctly prints 0 Virtually, Michael D. Morris |
From: Michael M. <mor...@gm...> - 2010-09-14 22:31:55
|
Oops! The second part of the bug report was a user error, not a bug. The first part of the test case is still returning xt 0 for user defined words though. |
From: Michael M. <mor...@gm...> - 2010-09-14 20:52:51
|
As of version 6.2, FIND seems to be both returning incorrect values for user defined words, and underflowing the stack. Here is the code to reproduce these errors with: : [defined] bl word find nip 0<> ; : [undefined] bl word find nip 0= ; : no-op ; [defined] no-op . \ should print -1 [undefined] no-op . \ should print 0 [defined] + . \ should print -1 [undefined] + . \ should print 0 \ This will crash with a stack underflow error bl word find no-op . . bl word find + . . Virtually, Michael D. Morris |
From: Michael M. <mor...@gm...> - 2009-05-26 06:59:48
|
Thanks, Reinhold. That fixed the problem nicely. I have to say, you guys sure fix bugs quickly. Virtually, Michael D. Morris. |
From: Mike H. <mik...@aa...> - 2009-05-25 22:25:27
|
Hi Reinhold, Thanks for the fix - as you say, this was a bug though not one that affected too many people! Cheers, Mike. > Hi Michael, > > well, the final step wasn't too complicated. Now vectoring the prompt > word should work in the Powermops console and from Quickedit as well, > and the vector will still be called "OK": > > 1) In file pnuc2, add a line: > ' (ok) vect OK > ' (ok) vect currentOK > > 2) In file zFrontend, add lines to: > :f NEWVECS > tNEWVECS -> whichVec \ Last Revision: 11/14/03 05:57:16 AM dbh > \ ['] (ok) -> OK \ <- comment out this line > ['] OK -> currentOK \ <- add this line > ... > :f OLDVECS > tOLDVECS -> whichVec \ Last Revision: 11/14/03 05:57:26 AM dbh > \ ['] (ok) -> OK \ <- comment out this line > ['] OK -> currentOK \ <- add this line > ... > :f >QECONS \ Last Revision: 11/10/03 07:25:19 PM dbh > t>QECONS -> whichVec \ Last Revision: 11/14/03 05:57:26 AM XXX > true -> prompt? > ['] qeOK -> currentOK \ <- add this line > > 3) In file MLTEFwindMod.txt edit word : EvalFromQE > : EvalFromQE \ { \ ret? -- } > \ Evaluates contents of QEstr. > false -> ret_in_qestr? > (...) > prompt? fWind? or IF currentOK THEN \ <- change this line > prompt? IF cr THEN > ; > > 4) rebuild Powermops from (68k-)Mops. > > > Actually, you found a bug, and a fix - either this one or a better one - > should be put into the next release. > > Cheers, > Reinhold > -- --------------------------------------------------------------- Mike Hore mik...@aa... --------------------------------------------------------------- |
From: Reinhold S. <dem...@we...> - 2009-05-25 15:36:38
|
Hi Michael, well, the final step wasn't too complicated. Now vectoring the prompt word should work in the Powermops console and from Quickedit as well, and the vector will still be called "OK": 1) In file pnuc2, add a line: ' (ok) vect OK ' (ok) vect currentOK 2) In file zFrontend, add lines to: :f NEWVECS tNEWVECS -> whichVec \ Last Revision: 11/14/03 05:57:16 AM dbh \ ['] (ok) -> OK \ <- comment out this line ['] OK -> currentOK \ <- add this line ... :f OLDVECS tOLDVECS -> whichVec \ Last Revision: 11/14/03 05:57:26 AM dbh \ ['] (ok) -> OK \ <- comment out this line ['] OK -> currentOK \ <- add this line ... :f >QECONS \ Last Revision: 11/10/03 07:25:19 PM dbh t>QECONS -> whichVec \ Last Revision: 11/14/03 05:57:26 AM XXX true -> prompt? ['] qeOK -> currentOK \ <- add this line 3) In file MLTEFwindMod.txt edit word : EvalFromQE : EvalFromQE \ { \ ret? -- } \ Evaluates contents of QEstr. false -> ret_in_qestr? (...) prompt? fWind? or IF currentOK THEN \ <- change this line prompt? IF cr THEN ; 4) rebuild Powermops from (68k-)Mops. Actually, you found a bug, and a fix - either this one or a better one - should be put into the next release. Cheers, Reinhold |
From: Doug H. <dho...@ta...> - 2009-05-25 14:39:13
|
On May 25, 2009, at 2:29 AM, Michael Morris wrote: > Every time I set OK to something, it reverts back to it's default the > next time I type anything in. > Here is an example of what I happens when I try: > > TRUE -> PROMPT? > > : PAGE ClrWind ; > > : (OK) ." ok" ; > > ' (OK) -> OK ok > 1 + 2 . 2 > > > Does any one have an idea as > to why OK keeps > resetting itself? I am assuming you are using the PowerMops window as console, not a QuickEdit window as console. In file zFrontend we have this definition, which resets OK to the system (ok) : :f NEWVECS tNEWVECS -> whichVec \ Last Revision: 11/14/03 05:57:16 AM dbh ['] (ok) -> OK \ Last Revision: 07/31/03 05:57:00 AM dbh ['] xemit -> emitvec ['] xcr -> crvec ['] xtyp -> typevec ['] xsps -> spvec ['] xemit -> echovec ['] setTW -> setfWind ['] xquit -> quitvec ['] bye+ -> byevec ;f We also have :f __doInterpret false -> __doInterpret? interpret: TW ;f Where interpret: is defined in file MLTEFwindMod.txt: :m INTERPRET: { \ echoCR? strt end -- } whichVec -> savedVec \ Last Revision: 11/14/03 06:08:20 AM DBH newvecs unlock: QEstr \ can be left locked by a prev err getSelect: theMLTEview -> end -> strt strt end = IF \ nothing selected strt 0EXIT \ right at the beginning we seem \ to run into problems unless we \ bail right out QEstr setStringFromLine: theMLTEview true -> echoCR? ELSE \ we have a hilited selection QEstr setStringFromSelection: theMLTEview THEN \ lineEnd: theTEscroller dup setselect: theTEscroller \ we don't have an easy way of locating a line yet, so let's try this: getselect: theMLTEview nip dup setselect: theMLTEview echoCR? IF cr THEN evalFromQE flush_TWstr actw ^TW <> IF 2dup ds: theStack 2drop \ 2dup 2dup ds: theStack 2drop 2drop THEN \ If another window is in front, we won't get an idle message, \ so we need to explicitly draw the stack. The 2dup and 2drop \ are so we have the same number of "extra" cells as we do on \ an idle message. \ Last Revision: 11/14/03 06:26:12 AM dbh restore the vecs savedVec CASE[ tNewVecs ]=> newvecs [ tOldVecs ]=> newvecs [ t>QECONS ]=> >QECONS default=> newvecs ]CASE ;m Where NEWVECS is getting called quite a bit. You might try redefining NEWVECS above to always set OK to what you want. Then recompile. Regards, -Doug |
From: Reinhold S. <dem...@we...> - 2009-05-25 14:11:53
|
Michael Morris wrote: >This happens wether or not I load ANSI. Does any one have an idea as >to why OK keeps >resetting itself? Hi Michael, this resetting comes from drawing the stackview. See method DS: in class Stackview (file MLTEFwindMod.txt). Somewhere in the middle the word oldvecs gets called, and near the end the word newvecs. Both these words are defined in file zFrontend. The second line of their definitions is ['] (ok) -> OK This does the unfortunate resetting of OK. To fix this, comment out these lines in newvecs and oldvecs, and rebuild Powermops from the nucleus PMops32 (or perhaps PMops64). There still is some trouble: if you use Quickedit in console view mode, it sets the prompt to "ok". That's ok, but when you return to the Powermops console, the prompt will still be "ok". This is a bit harder to fix. 1) In file pnuc2, add a line: ' (ok) vect OK ' (ok) vect saveOK 2) In file zFrontend, add lines to :f newvecs and :f oldvecs :f NEWVECS tNEWVECS -> whichVec \ Last Revision: 11/14/03 05:57:16 AM dbh \ ['] (ok) -> OK \ Last Revision: 07/31/03 05:57:00 AM dbh ['] saveOK -> OK ... :f OLDVECS tOLDVECS -> whichVec \ Last Revision: 11/14/03 05:57:26 AM dbh \ ['] (ok) -> OK \ Last Revision: 07/31/03 05:57:00 AM dbh ['] saveOK -> OK ... 3) rebuild Powermops from (68k-)Mops. Now, still something... you'll have to change the prompt not by ' (OK) -> OK but by ' (OK) -> saveOK This can be fixed, too, but maybe that is not too urgent ;-) Cheers, Reinhold |
From: Doug H. <dho...@ta...> - 2009-05-25 12:08:23
|
On May 25, 2009, at 2:29 AM, Michael Morris wrote: Or if things get too confusing one could redefine the system (ok) in file pnuc2 (in folder PPC source ) and recompile: \ Doug H wants the prompt vectored: : (ok) & > emit ; ' (ok) vect OK Regards, -Doug |
From: Mike H. <mik...@aa...> - 2009-05-25 09:56:26
|
Michael Morris wrote: > Every time I set OK to something, it reverts back to it's default the > next time I type anything in. > Here is an example of what I happens when I try: > > // ANSI > Loading: ANSI > Loading: double Code: 1968 data: 0 > Loading: String+ Code: 13016 data: 284 > Loading: zFloating point Code: 23196 data: 220 > Code: 48180 data: 548 > > TRUE -> PROMPT? > > : PAGE ClrWind ; > > : (OK) ." ok" ; > > ' (OK) -> OK ok > 1 + 2 . 2 > > > This happens wether or not I load ANSI. Does any one have an idea as > to why OK keeps > resetting itself? Hi Michael, Did you save the dictionary after you made the change? AFAIR that should work, though it's years since I looked in this area. Cheers, Mike. --------------------------------------------------------------- Mike Hore mik...@aa... --------------------------------------------------------------- |
From: Michael M. <mor...@gm...> - 2009-05-25 06:29:22
|
Every time I set OK to something, it reverts back to it's default the next time I type anything in. Here is an example of what I happens when I try: // ANSI Loading: ANSI Loading: double Code: 1968 data: 0 Loading: String+ Code: 13016 data: 284 Loading: zFloating point Code: 23196 data: 220 Code: 48180 data: 548 TRUE -> PROMPT? > : PAGE ClrWind ; > : (OK) ." ok" ; > ' (OK) -> OK ok 1 + 2 . 2 > This happens wether or not I load ANSI. Does any one have an idea as to why OK keeps resetting itself? Confusedly, Michael D. Morris. |
From: Reinhold S. <dem...@we...> - 2008-08-07 07:40:16
|
Hi Michael! First, you must have MacOS 9 installed. Open folder CFM-32bit. (There are also folders MachO-32 and MachO-64; MachO is the preferred file format for executables, and programs in MachO format should start up faster then those in traditional Code Fragment Manager format. In practice however, I don't notice much difference in speed - Powermops starts up very fast anyway. But in order to build MachO-Powermops, you'll have to set file permissions in Unix, so its more cumbersome; I never do it, so here I'll describe how to build a CFM version.) Ok, right-click (or control-click) on the application icon and choose "Show Package Contents" from the contextual menu. You will see a "Contents" folder; navigate into this folder and you will see the "MacOS" and "Resources" directory. Open the "MacOS" folder. There you find a file "mops.dic" and an application "Mops". Drag the icon of "mops.dic" onto the icon of "Mops"; don't double-click! (Another Mops-Application in another Powermops package might open and use the sources which are *there*, not your changed sources.) Type // ppc.ld and hit the enter key. This will build an application named "PMops32" in folder "MacOS". This is the PMops nucleus. For subsequent experimentation, you can start rebuilding Powermops by opening this application - you normally won't need to start with System 9 and Mops again. So start PMops32 and type // ppc1.ld and hit the enter key. The application will terminate itself and you'll see (hopefully) an updated application file "Powermops" in folder "MacOS". Now you're done and should experience the new behaviour of Powermops. Hope that helps. Cheers, Reinhold Straub |
From: Michael M. <mor...@gm...> - 2008-08-07 00:40:32
|
I asked on comp.lang.forth.mac a while ago how to get the Mops term- inal to print text output on the same line as the input like so: : 2+2 ." = 4" ; 2+2 = 4 ok I got a response that said to change INTERPRET: in MLTEFwindMod, and the rebuild PowerMops from the PMops nucleus. I've edited the file, but I'm not sure how to rebuild Mops on my MacBook Pro. Should I run Mops 4.0 in Basillisk? Virtually, Michael Morris. |
From: Mike H. <mik...@aa...> - 2006-08-22 22:08:58
|
Hi Nao, > Mike Hore wrote: >> "Strongly dislike" is a big of an understatement... >> I could also add that our PowerPC experience was that it took about 5 >> years to shake out all the code generator bugs, and even now an >> occasional one still shows up. Will Macs still be running on >> Intel in >> 5 years time? I'd say not on 32-bit Intel hardware at least. > > 64-bit Mac Pro was released, and Leopard (Mac OS X 10.5) is advertised > as a full 64-bit OS (Carbon and Cocoa will get to full 64-bit at > last). > So I guess Intel Mac will go to 64-bit in few years, maybe except for > MacBook. There we are then. But I've now got an idea that even 64-bit hardware might be running out of time -- as I recently posted on comp.lang.forth, ever since 1960 or so we've needed about one and a half more address bits per year, and this trend has been amazingly consistent. If this holds up, even 64 bits will be getting a bit short by 2010. Maybe some completely new architecture is round the corner!! > > So I think, if PowerMops will be ported to Intel Mac, it will be a > port > for Leopard. Fortunately, Leopard is said still to run with PowerPC, > PowerPC Mac will not disappear in a year or two. I agree. Apple appears to be still committed to the PowerPC architecture, at least with Rosetta. Though, once they're selling 64-bit Intel Macs, I'm sure they won't sell any more PowerPC Macs. > > By the way, PowerMops has the robust and optimized code generator for > PowerPC. So I think it would be good to port PowerMops to PPC Linux > with XWindow, Gnome or GTK+. I agree, this would be good. And maybe a bit easier than a new code generator. Though of course a new system API still means a big job. > > Anyway, Mops will never die. ;-) True!! Cheers, Mike. --------------------------------------------------------------- Mike Hore mik...@aa... --------------------------------------------------------------- |
From: Nao S. <sac...@yb...> - 2006-08-22 15:01:00
|
Hi all, Mike Hore wrote: > "Strongly dislike" is a big of an understatement... > I could also add that our PowerPC experience was that it took about 5=20= > years to shake out all the code generator bugs, and even now an=20 > occasional one still shows up.=A0 Will Macs still be running on Intel = in=20 > 5 years time?=A0 I'd say not on 32-bit Intel hardware at least.=A0=A0 64-bit Mac Pro was released, and Leopard (Mac OS X 10.5) is advertised=20= as a full 64-bit OS (Carbon and Cocoa will get to full 64-bit at last).=20= So I guess Intel Mac will go to 64-bit in few years, maybe except for=20 MacBook. So I think, if PowerMops will be ported to Intel Mac, it will be a port=20= for Leopard. Fortunately, Leopard is said still to run with PowerPC,=20 PowerPC Mac will not disappear in a year or two. By the way, PowerMops has the robust and optimized code generator for=20 PowerPC. So I think it would be good to port PowerMops to PPC Linux=20 with XWindow, Gnome or GTK+. Anyway, Mops will never die. ;-) Sincerely, Nao Sacrada |
From: Doug H. <dho...@ta...> - 2006-08-20 14:41:12
|
Not the definitive set of tests, but it may provide some insight: Benchmarks based on tests by Doug Hoffman(PPC) and Roelf Toxopeus(inteliMac): : SQR ( x -- x^2 ) DUP * ; 100000000 VALUE #do : BAR-PICK-FULL2 ( a b c x -- y ) 3 PICK OVER * OVER * 3 PICK 2 PICK * + 2 PICK + -ROT 2DROP -ROT 2DROP ; : bar-pick-full3 ( c b a x -- y ) >R R@ * + R> * + ; : bar-pick-full4 ( a b c x -- y ) >R SWAP ROT R@ * + R> * + ; : bar-params3 { a b c x -- y } x sqr a * x b * + c + ; : bar-params4 { a b c x -- y } x x * a * x b * + c + ; : bar-params5 { a b c x -- y } a x * b + x * c + ; : TEST ( -- ) CR ." bar-pick-full2 : " 0 timer-reset #do 0 ?DO 1 2 3 4 bar-pick-full2 + LOOP DROP .elapsed CR ." bar-pick-full3 : " 0 timer-reset #do 0 ?DO 3 2 1 4 bar-pick-full3 + LOOP DROP .elapsed CR ." BAR-PICK-FULL4 : " 0 timer-reset #do 0 ?DO 1 2 3 4 bar-pick-full4 + LOOP DROP .elapsed CR ." bar-params3 : " 0 timer-reset #do 0 ?DO 1 2 3 4 bar-params3 + LOOP DROP .elapsed CR ." bar-params4 : " 0 timer-reset #do 0 ?DO 1 2 3 4 bar-params4 + LOOP DROP .elapsed CR ." bar-params5 : " 0 timer-reset #do 0 ?DO 1 2 3 4 bar-params5 + LOOP DROP .elapsed ; Computer = iMac G3 500 MHz OS X Panther 10.3.9 test \ Mops 6.0 release bar-pick-full2 : 9.93 seconds bar-pick-full3 : 5.40 seconds bar-pick-full4 : 5.81 seconds bar-params3 : 5.63 seconds bar-params4 : 3.03 seconds bar-params5 : 2.60 seconds ok Computer = MacBook 1.83 GHz Intel Core Duo OS X Tiger 10.4.7 test \ Mops 6.0 release bar-pick-full2 : 11.516 seconds bar-pick-full3 : 3.366 seconds bar-pick-full4 : 3.600 seconds bar-params3 : 3.266 seconds bar-params4 : 2.983 seconds bar-params5 : 2.916 seconds ok |
From: Doug H. <dho...@ta...> - 2006-08-20 11:37:38
|
On Aug 20, 2006, at 1:53 AM, dim seldom wrote: > Hi I was wondering if you had any plan in porting powermops to the new > OSX > Tiger with intel Duo processors? As all the new generation of mac have > been > officially converted to that new processor and all the power pc and > 68k are > quickly fading away. I do enjoy learning powermops but I would not > apreciate > investing a lot of time in a product that may be at its final breath. > So you > intention would be greatly apreciated. Thank you. Dims I recently saw some benchmark speed comparisons of both PowerMops and Carbon MacForth. The benchmarks were run on a PPC Mac and an inteliMac. First, both PowerMops and Carbon MacForth run just fine as-is on the inteliMac. Second, their speeds were just fine on the inteliMac compared to the PPC, although I don't have the processor speeds that were used in this test. Not exactly the question you asked, I know. But this tells me that regardless of what happens, PowerMops is already compatible with an an inteliMac. Same can be said for Carbon MacForth. Regards, -Doug |
From: dim s. <dim...@ho...> - 2006-08-20 05:53:46
|
Hi I was wondering if you had any plan in porting powermops to the new OSX Tiger with intel Duo processors? As all the new generation of mac have been officially converted to that new processor and all the power pc and 68k are quickly fading away. I do enjoy learning powermops but I would not apreciate investing a lot of time in a product that may be at its final breath. So you intention would be greatly apreciated. Thank you. Dims _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ |
From: Nao S. <sac...@yb...> - 2006-07-24 13:13:58
|
Hi All, I found utility functions for FP mathematics, sin, cos, tan, etc. are moved to System.framework. Those are included in CarbonLib, so PEF/CFM PowerMops can syscall them but MachO PowerMops can't. So if you will use FP mathematical utility words (FSIN, FCOS, FTAN, etc.) on MachO PowerMops, file "zfloating point" should be modified, although basic FP functionality works without modifications. (System.framework may be better added to libraries to be searched in by syscall in case of MachO PowerMops.) For example: In file "zFloating point" in folder "Mops source:System source:", (from line 571) [code] \ ================================== \ Transcendentals etc. \ ================================== MACHO? [IF] Framework System.framework frwkcall sin { %deg -- %sin } frwkcall cos { %deg -- %cos } frwkcall tan { %deg -- %tan } frwkcall asin { %sin -- %deg } frwkcall acos { %cos -- %deg } frwkcall atan { %tan -- %deg } frwkcall atan2 { %y %x -- %deg } frwkcall sinh { %x -- %sinhx } frwkcall cosh { %x -- %coshx } frwkcall tanh { %x -- %tanhx } frwkcall asinh { %sinhx -- %x } frwkcall acosh { %coshx -- %x } frwkcall atanh { %tanhx -- %x } frwkcall exp { %x -- %expx } frwkcall expm1 { %x -- %expX-1 } frwkcall pow { %x %y -- %x^Y } frwkcall log { %x -- %lnx } frwkcall log1p { %x -- %ln(1+x) } frwkcall log10 { %x --%logx } frwkcall sqrt { %x -- %sqrtX } [ELSE] syscall sin syscall cos syscall tan syscall asin syscall acos syscall atan syscall atan2 syscall sinh syscall cosh syscall tanh syscall asinh syscall acosh syscall atanh syscall exp syscall expm1 syscall pow syscall log syscall log1p syscall log10 syscall sqrt [THEN] ... [code-end] That's all. Sincerely, Nao Sacrada |
From: Reinhold S. <dem...@we...> - 2006-06-18 09:44:35
|
Hi Mike and Nao, thank you very much for helping me with the assembler. I've written a class "set" which implements set operations via bitvectors. Now I want to use AltiVec for the bitvector operations: but class "vectors" has only a tiny fraction of the 162 or so instructions of AltiVec. In particular I need "andc" for the set difference operation. This is how I do it for word_vectors: :ppc_code difference ( adr1 adr2 adr3 -- ) r5 4 rSP lwz, v1 r0 r5 lvxl, v2 r0 r3 lvxl, v0 v1 v2 vandc, v0 r0 r4 stvx, \ now drop parameters: r4 20 rSP lwz, r3 28 rSP lwz, rSP 24 addi, blr, ;ppc_code \ Thank you Nao for pointing out the correct offsets from rSP! The corresponding method is: :m diff->: ( adr1 adr2 -- ) ^base difference ;m For long_word_vectors: :ppc_code longdifference ( adr1 adr2 adr3 #bytes -- ) r5 4 rSP lwz, r6 12 rSP lwz, begin, r4 0 cmpi, ne while, r4 r4 -16 addi, v1 r4 r6 lvxl, v2 r4 r5 lvxl, v0 v1 v2 vandc, v0 r4 r3 stvxl, repeat, r4 20 rSP lwz, r3 28 rSP lwz, rSP 32 addi, blr, ;ppc_code :m diff->: { src1 src2 -- } src1 16 + src2 16 + ^base 16 + (limit) cells longdifference ;m Unfortunately, this seems to be less efficient than the other long vector methods, so instead of calling "diff->:" it should be better to write its code inline. Cheers, Reinhold |
From: Mike H. <mik...@aa...> - 2006-06-17 01:01:25
|
Hi Doug and Nao, > Hi Nao, > I see no downside at all as long as users are given the caveats as you > have outlined. As I said, Ward has implemented something which I > think > is exactly the same mechanism and I have found it to be an invaluable > feature of Carbon MacForth (aka QuickEdit to me).. > > But certainly something like this is Mike's decision. Perhaps it > needs > more testing by the beta group and it could be used in a future > release > if it proves itself. This looks like a good idea to me, though as you all know I don't have any time for testing it just now. I think I'll "silently" put it into the PPC source folder in the upcoming release ;-) -- Mike. > > Regards, > > -Doug > > > Nao wrote: > >> Hi Doug, >> >> Thank you for the dangerous testing! ;-) >> >> Doug Hoffman wrote: >>> >>> I vote for making this a standard part of the PowerMops release. Is >>> there a downside? >>> >> >> Putting a file silently into, for example, PPC source folder, >> might do >> no harm ;-). >> >> Seriously, there are two problems I have realized.: >> >> 1. After "die", return stack pointer will be reverted >> to the initial state. This may cause some event handling problems >> when your application has its own "EventLoop" word -- I myself have >> written >> such one. >> In such a case, calling your EventLoop word again after "DIE" >> seems to fix the problem. >> >> Normal commands such as inspecting values or variables or ivars >> will work. >> >> 2. The code is supposing 32Bit PPC. It might not give correct >> information >> on 64Bit PPC. >> >> Sincerely, >> Nao Sacrada > > > > _______________________________________________ > PowerMops-USERS mailing list > Pow...@li... > https://lists.sourceforge.net/lists/listinfo/powermops-users --------------------------------------------------------------- Mike Hore mik...@aa... --------------------------------------------------------------- |
From: Nao S. <sac...@yb...> - 2006-06-16 15:13:52
|
Hi Doug, Doug Hoffman wrote: > As I said, Ward has implemented something which I think > is exactly the same mechanism and I have found it to be an invaluable > feature of Carbon MacForth (aka QuickEdit to me).. I forgot to mention it. Yes, my code imitated Carbon MacForth. I got Demo version of Carbon MacForth to see the standard Macintosh Forth. But it was not long until I made MacForth crash by wrong code... Then I found a crash log file was created. I was impressed by the fact that the log file contained really complete information. What I did was a mere incomplete copy of a feature of Carbon MacForth. But information of integer registers and disassembled code around crashed point might help debugging. Sincerely, Nao Sacrada |
From: Doug H. <dho...@ta...> - 2006-06-16 13:56:53
|
Hi Nao, I see no downside at all as long as users are given the caveats as you have outlined. As I said, Ward has implemented something which I think is exactly the same mechanism and I have found it to be an invaluable feature of Carbon MacForth (aka QuickEdit to me).. But certainly something like this is Mike's decision. Perhaps it needs more testing by the beta group and it could be used in a future release if it proves itself. Regards, -Doug Nao wrote: > Hi Doug, > > Thank you for the dangerous testing! ;-) > > Doug Hoffman wrote: >> >> I vote for making this a standard part of the PowerMops release. Is >> there a downside? >> > > Putting a file silently into, for example, PPC source folder, might do > no harm ;-). > > Seriously, there are two problems I have realized.: > > 1. After "die", return stack pointer will be reverted > to the initial state. This may cause some event handling problems > when your application has its own "EventLoop" word -- I myself have > written > such one. > In such a case, calling your EventLoop word again after "DIE" > seems to fix the problem. > > Normal commands such as inspecting values or variables or ivars > will work. > > 2. The code is supposing 32Bit PPC. It might not give correct > information > on 64Bit PPC. > > Sincerely, > Nao Sacrada |
From: Nao S. <sac...@yb...> - 2006-06-16 13:47:08
|
Hi Doug, Thank you for the dangerous testing! ;-) Doug Hoffman wrote: > > I vote for making this a standard part of the PowerMops release. Is > there a downside? > Putting a file silently into, for example, PPC source folder, might do no harm ;-). Seriously, there are two problems I have realized.: 1. After "die", return stack pointer will be reverted to the initial state. This may cause some event handling problems when your application has its own "EventLoop" word -- I myself have written such one. In such a case, calling your EventLoop word again after "DIE" seems to fix the problem. Normal commands such as inspecting values or variables or ivars will work. 2. The code is supposing 32Bit PPC. It might not give correct information on 64Bit PPC. Sincerely, Nao Sacrada |