Thanks Philippe
Sounds like good news.
> Hi! Great advances in the poplog port to OS X.
I look forward to hearing that it runs on this:
http://www.apple.com/macmini/
> We now have it initializing, and the console is prompting for commands.
>
> We do have a new problem.
>
> When we type an instruction the system does not
> execute it correctly, we are trying to figure out what is
> happening, so we modified the function sysPUSHQ in
> vm_plant.p in order to evaluate the "bye" instruction
This is probably not a good place to start, since as Jonathan pointed
out 'bye' is a macro and is autoloaded, so in order to test it you have
to have a lot of stuff already working, including the autoloading
mechanism (see HELP AUTOLOAD), compiler search lists, the compilation
and expansion of macros, etc.
As Jonathan suggested you first need to investigate that much simpler
things work, e.g.
- putting things on the stack and printing out the stack contents:
1 =>
1, 2, 3 =>
- simple arithmetic
1 + 2 =>
1.0 + 2.0 =>
99 * 9 =>
sqrt(100) =>
sqrt(-1) =>
(should print
** 0.0_+:1.0
)
- creation of a word and printing it out
"hello" =>
- creation of strings and printing
'a silly string' =>
'a string ' >< 'joined to another' =>
- list creation and printing
[one two 3 4] =>
[an [embedded list] 'with a string'] =>
[joining up] <> [two lists] =>
- Detecting and reporting errors
1 2 =>
;;; MISHAP msep: MISSING SEPARATOR (eg semicolon): 1 2
;;; (At or before line 8574 column 5)
"one" + "two" =>
;;; MISHAP - NUMBER(S) NEEDED
;;; INVOLVING: one two
;;; FILE : /home/staff/axs/grants.d/osx/osx LINE NUMBER: 8578
;;; DOING : + runproc pop_setpop_compiler
- defining and running procedures
define add_two(x, y) -> result;
x + y -> result
enddefine;
add_two(99, 100) =>
** 199
=====
And other things in the pop11 primer.
If you don't get expected results and you need help, you'll need to
report *exactly* what you did and *exactly* what results it produced.
Most people reading these messages (including me) have never done a port
of poplog so in many ways you are now more experienced than we are, and
we will not necessarily recognize the context of a problem you have.
One thing I noticed recently:
In the file $popsrc/syscomp/sysdefs.p for linux there is this bit:
;;; Include M-code listing in assembly language files
M_DEBUG = false,
Have you tried setting that true and rebuilding popc.psv ?
It may be worth doing as a last resort if you have obscure problems.
I don't where you inserted this, or what you expected it to do.
>
> when we execute newpop11 on LINUX and type the command
> "bye" on the console we have the following printing
> result:
>
> SyspushQ: sysexit
> SyspushQ: (
> SyspushQ: )
> SyspushQ: ;
>
> Entro a sysexit
>
> And after that, it exits the application normally.
>
> On OS X we get this results:
>
> SyspushQ: sysexit
> SyspushQ: (
> SyspushQ: )
> SyspushQ: ;
That suggests to me that popautolist is working, the macro bye got
compiled, and bye ran the commands to put those four words on the
stack.
After the macro exists, the compiler should put the things left on the
stack onto the front of proglist and compiled them.
You can check if simple macros are working (see help macro);
define macro xxxx;
3, "+", 4, "=>"
enddefine;
Then
xxxx
should print
** 7
If not, there may be something wrong with list manipulation (unlikely)
or with the way the dynamic list proglist is handled (see REF PROGLIST)
or something to do with the way poplog VM code is planted.
But macros may be fine, and sysexit may not be working.
The procedure sysexit is defined in $popsrc/sysexit.
It does various things and eventually invokes Opsys_exit, defined in
$popsrc/setpop.p
Maybe you could add print instructions in sysexit, e.g.
1 =>
2 =>
etc. to see how far it gets.
> What should happen then is sysexit being called. We would
> like to know what exactly should be called once these SyspushQ
> are done.
As jonathan said, test sysexit directly without using the macro "bye".
Good luck!
Aaron
|