[split] Emu71 on Linux memory crashes

[split] Emu71 on Linux memory crashes - Printable Version

+- HP Forums (https://www.hpmuseum.org/forum)
+-- Forum: HP Calculators (and very old HP Computers) (/forum-3.html)
+--- Forum: General Forum (/forum-4.html)
+--- Thread: [split] Emu71 on Linux memory crashes (/thread-20697.html)

[split] Emu71 on Linux memory crashes - floppy - 10-23-2023 05:46 PM

I am currently using EMU71 1.14 on Linux. Good stuff. Now trying to debug a program which created 2x memory lost..
After putting 128KB RAM, I started a program and was testing (Forth/ASM) when an error "ERR:Insufficient Memory" appeared. So far ok. Then all uploaded forth words were gone.
How to check the currently available RAM on EMU71? (the free available). The ROOM? Forth word could perhaps has done it (but was gone). Then next I will search why all words were gone without bigger warnings.

RE: Update of Emu71/Win to v1.14 - Sylvain Cote - 10-23-2023 06:46 PM

(10-23-2023 05:46 PM)floppy Wrote: How to check the currently available RAM on EMU71? (the free available).

mmm, maybe

open up the HP-71B User's Manual
look into the index at M (p.301) → Memory → Unused amount of, in RAM ... (p.107)
Obtaining Memory Information (p.107) → MEM[(port number)]
→ ex.1: MEM
→ ex.2: MEM(5)

RE: [split] Emu71 on Linux memory crashes - floppy - 10-26-2023 04:25 PM

My current analysis show that it must be an addressing conflict during the use of a program (because a word in dictionnary cannot be found after a first execution.. and the memory loss appear.. even after update to EMU71 V1.17).

By defining a test HERE 0 , 0 , 0 , 0 , HERE SWAP - .
20 OK { 0 }
has the same behaviour like HERE 4 5 * NALLOT HERE SWAP - .
20 OK { 1 }

Now for storing and retrieving data from such vocabularies entries, what to use? N@ or @?
And storing would be N! or ! ?.

I dont see the reason why ! or @ are not listed in the Forth manual page 14. And could be the differences. Any hint is welcome.

RE: [split] Emu71 on Linux memory crashes - rprosperi - 10-27-2023 12:43 AM

(10-26-2023 04:25 PM)floppy Wrote: My current analysis show that it must be an addressing conflict during the use of a program (because a word in dictionnary cannot be found after a first execution.. and the memory loss appear.. even after update to EMU71 V1.17).

By defining a test HERE 0 , 0 , 0 , 0 , HERE SWAP - .
20 OK { 0 }
has the same behaviour like HERE 4 5 * NALLOT HERE SWAP - .
20 OK { 1 }

Now for storing and retrieving data from such vocabularies entries, what to use? N@ or @?
And storing would be N! or ! ?.

I dont see the reason why ! or @ are not listed in the Forth manual page 14. And could be the differences. Any hint is welcome.

Standard 16-bit Forth uses @ for fetch and ! for store. The 71B uses nibbles (4-bits, half a byte) as the atomic address increment instead of bytes, so the N@ and N! commands are used to replace @ and !, and C@ / C! for byte-sized values, but you have to also shift the logic of your programs to access nibble-sized values. Porting existing Forth code that assumes 16-bit values will essentially never work as-is, due to the nibble vs. byte assumptions underlying the logic.

RE: [split] Emu71 on Linux memory crashes - floppy - 10-27-2023 07:31 AM

" N@ and N! commands are used to replace @ and ! "

Since all these 4 words are in HP71B Forth, what are their difference?
Or @ and ! are just there and the same than N@ and N! ?

RE: [split] Emu71 on Linux memory crashes - rprosperi - 10-27-2023 12:13 PM

@ fetches 20-bit values from the specified address

C@ fetches 8-bit values from the specified address (often used for characters)

N@ fetches 4-bit values from the specified address

and the same for the ! equivalents

Most existing Forth code assumes @ will get 16-bit values.

hth

RE: [split] Emu71 on Linux memory crashes - Jeff_Birt - 10-27-2023 01:49 PM

(10-27-2023 07:31 AM)floppy Wrote: " N@ and N! commands are used to replace @ and ! "

Since all these 4 words are in HP71B Forth, what are their difference?
Or @ and ! are just there and the same than N@ and N! ?

I was not sure about this either as I am just learning to use my HP-71. Looking at the HP-71 FORTH manual just now I see they specified the differences up front in the manual on pages 13-14. The problem of what is the size of a data type is somewhat common, especially on older systems. Not only in FORTH but in C for example it would not be uncommon for the size of an INT to vary from platform to platform, so the programmer has to keep this in mind.

file:///C:/Users/birtj/Downloads/82441-90001_71_FORTH-AssemblerROM_OwnersManual_155pages_Apr84.pdf

RE: [split] Emu71 on Linux memory crashes - Eric Rechlin - 10-28-2023 04:33 AM

(10-27-2023 01:49 PM)Jeff_Birt Wrote: I was not sure about this either as I am just learning to use my HP-71. Looking at the HP-71 FORTH manual just now I see they specified the differences up front in the manual on pages 13-14. The problem of what is the size of a data type is somewhat common, especially on older systems. Not only in FORTH but in C for example it would not be uncommon for the size of an INT to vary from platform to platform, so the programmer has to keep this in mind.

file:///C:/Users/birtj/Downloads/82441-90001_71_FORTH-AssemblerROM_OwnersManual_155pages_Apr84.pdf

Unfortunately that link doesn't work. Here's a good link for that file:

http://www.hpmuseum.net/document.php?hwfile=5766

RE: [split] Emu71 on Linux memory crashes - floppy - 10-29-2023 05:08 PM

we see following in direct entries from the keyboard (similar during execution)

a) on gforth > -1 200 mod . output 199 (the result is what I wanted to see; on a 64bits computer)
b) on EMU71 > -1 200 MOD . output -1 (I would like to see 199)

For this reason, some address arithmetic for storing dont work well on EMU71 (I try to reproduce a working gforth program in an EMU71 first, later will be done on HP71B).

Any hint where this difference of behaviour is coming from, is welcome.

I will search now arithmetic differences between 32 and 8 bits processors; if I remember this could explain and countermeasures could be identified.

RE: [split] Emu71 on Linux memory crashes - rprosperi - 10-29-2023 11:34 PM

If you look at page 130 in the 71B Forth manual, it's description for MOD is:

{n1 n2 -> n3 } Divide n1 by n2, and return the remainder n3 with the same sign as n1.

Perhaps the Forth standard between Forth-83 (which 71B mostly follows) and gforth has changed how it defines MOD.

This is about the 20th question you've asked, where folks here read you answers from the manual. Don't you think it's about time you actually read the manual all the way through or at least consult it before asking a question?

With respect, please don't waste any more of other people's time until you've at least tried to research answers yourself.

RE: [split] Emu71 on Linux memory crashes - floppy - 10-30-2023 07:35 AM

Nobody is forced to answer here. If any time and any patience, then its welcomed. And if the posts are disturbing, then the moderator can delete any time. looks like here a small boy reprimand at school. And again the moderator can delete this.

RE: [split] Emu71 on Linux memory crashes - floppy - 10-30-2023 07:42 AM

(10-29-2023 11:34 PM)rprosperi Wrote: {n1 n2 -> n3 } Divide n1 by n2, and return the remainder n3 with the same sign as n1.

What is the decision beyond this? the integer arithmetic? MOD implementation is heterogenous accross some systems: how to make it homogenous?
(referencing to a manual page is a good start. I could already read. Backgrounds in computer integer arithmetic would be goooood).

For example the HP71B stack looks like
-1 200 MOD
OK { 1 }
.S
1048575 OK { 1 }
-1 .S
1048575 1048575 OK { 2 }
As we see the -1 is stored with an integer (looks positive).
I further search and will find a solution: however, not easy to find the answer for such an old board quite nobody is using (I dont see an HP71 as collection part, but as part to be used for a precise identified task).

UPDATE: since I could not find a physical/processor reason for HP71B having implemented the MOD function differently like in gforth, I made a Gforth like new MOD function (only positive results). Now I will test if my memory arithmetic works fine with that modified MOD.

Code:

:  PMOD DUP -ROT MOD DUP 0< IF + ELSE NIP THEN  ;

RE: [split] Emu71 on Linux memory crashes - floppy - 10-30-2023 10:03 AM

(10-27-2023 01:49 PM)Jeff_Birt Wrote: I am just learning to use my HP-71.

Good. Like me.
My focus is: having a forth cross-development under gforth for easy hp71b forth writing and debugging (see CC41 philosophy; however it was written new in C, I am pragmatic / low effort and want to use the existing emacs UI and gforth). Advantage will be, the gforth programs (and HP71B) could have a high interoperability. Completion date? .. months years.. (few examples already working).
A pity is: we need a clonix71 with assembler because the forth modules are out of reach and not everybody has it (I am a lucky person to have bought an HP71B and discovered at delivery it had MATH and FORTH in the ports).
Why? brain jogging in between until I am busy with other more valuable things.

RE: [split] Emu71 on Linux memory crashes - Didier Lachieze - 10-30-2023 10:33 AM

(10-30-2023 10:03 AM)floppy Wrote: A pity is: we need a clonix71 with assembler because the forth modules are out of reach and not everybody has it (I am a lucky person to have bought an HP71B and discovered at delivery it had MATH and FORTH in the ports).

Just one word: MultiMod

RE: [split] Emu71 on Linux memory crashes - floppy - 10-30-2023 10:39 AM

(10-30-2023 10:33 AM)Didier Lachieze Wrote:
(10-30-2023 10:03 AM)floppy Wrote: A pity is: we need a clonix71 with assembler because the forth modules are out of reach and not everybody has it (I am a lucky person to have bought an HP71B and discovered at delivery it had MATH and FORTH in the ports).

Just one word: MultiMod

I was not aware the assembler module would work in it, should be hardwired in the front? If it works in MULTIMOD, then fine, topic solved (never tried it).

RE: [split] Emu71 on Linux memory crashes - Sylvain Cote - 10-30-2023 02:04 PM

(10-30-2023 10:39 AM)floppy Wrote: I was not aware the assembler module would work in it, should be hardwired in the front? If it works in MULTIMOD, then fine, topic solved (never tried it).

As usual, the information is in the user manual.

HP-71B MultiMod ROM Emulator