HP75C / FORTH / Clock?

[charger73]

With the new HP75 emulator EMU75 is makes fun to play with the existing software, for example FORTH.
While learning FORTH with the HP75 – I have transferred the N-Queens benchmark source code to the HP75:

http://www.hpmuseum.org/cgi-sys/cgiwrap/...i?read=700

SCR00005:
8 CONSTANT RR
0 VARIABLE SS
0 VARIABLE XX
0 VARIABLE YY
HEX HERE RR 1+ ALLOT CONSTANT AA
: RCLAA @ AA + C@ ;
: STOAA @ AA + C! ;
: NQCORE 0 SS ! 0 XX !
BEGIN 1 XX +! RR XX STOAA BEGIN 1 SS +! XX @ YY !
BEGIN YY @ 1 > WHILE -1 YY +! XX RCLAA YY RCLAA - DUP
0 = SWAP ABS XX @ YY @ - = OR IF 0 YY !
BEGIN XX RCLAA 1 - DUP XX STOAA 0 = WHILE -1 XX +! REPEAT THEN
REPEAT YY @ 1 = UNTIL RR XX @ = UNTIL ;
: NQUEENS NQCORE ." S=" SS @ . CR ;
DECIMAL


It works! The source is in the file “SCR00005” In the FORTH environment you can load it with “5 LOAD” and start it with “NQUEENS”

But now my question. How I can measure the runtime of the routine NQUEENS. I see no time command in the FORTH environment. Is there a clock memory address?
Who wrote a time routine? Thank you.

(I feel, it is very fast - later, i will try that on the real machine.)

Best regards
Tobie

[J-F Garnier]

(03-17-2017 02:00 PM)charger73 Wrote:  With the new HP75 emulator EMU75 is makes fun to play with the existing software, for example FORTH.
While learning FORTH with the HP75 – I have transferred the N-Queens benchmark source code to the HP75
...
But now my question. How I can measure the runtime of the routine NQUEENS. I see no time command in the FORTH environment. Is there a clock memory address?

That's a tough question!

The HP75 timer is made of 5 consecutive bytes at the same physical address in the I/O space. I see no way to read it from Basic (PEEK) or Forth, only a multibyte read opcode can do it from assembly.

I had a lot of interest in Forth at the time (but never used the HP75 version).
Now, Forth is definitely too cryptic and unstructured for me ...

J-F

[Garth Wilson]

(03-18-2017 08:43 AM)J-F Garnier Wrote:  The HP75 timer is made of 5 consecutive bytes at the same physical address in the I/O space. I see no way to read it from Basic (PEEK) or Forth, only a multibyte read opcode can do it from assembly.

It should be easy to make a primitive in Forth then to do it, right? (I have a 75C that someone gave me, pretty beat up and lacking the battery pack and manuals, and I never learned to use it. I did use my 71B heavily in the late 1980's, but never learned its assembly language.)

Quote:Now, Forth is definitely too cryptic and unstructured for me ...

That's the way I see C. An absolute disaster.

[Paul Berger (Canada)]

(03-18-2017 09:57 AM)Garth Wilson Wrote:  

(03-18-2017 08:43 AM)J-F Garnier Wrote:  The HP75 timer is made of 5 consecutive bytes at the same physical address in the I/O space. I see no way to read it from Basic (PEEK) or Forth, only a multibyte read opcode can do it from assembly.

It should be easy to make a primitive in Forth then to do it, right? (I have a 75C that someone gave me, pretty beat up and lacking the battery pack and manuals, and I never learned to use it. I did use my 71B heavily in the late 1980's, but never learned its assembly language.)

Quote:Now, Forth is definitely too cryptic and unstructured for me ...

That's the way I see C. An absolute disaster.

I don't understand either of these comments, both C and Forth provide plenty of constructs for for structured programming, however neither one of them forces you to use them.

[John Cadick]

Scuse my ignorance -- what HP75C simulator? I have found one for the android (alas I am married to iPhone).

Is there also one for the 71?

Where are they available?

John

[Dave Frederickson]

Jean-Francois Garnier's Emu75/DOS was announced two weeks ago.
https://groups.io/g/hp75/message/304?p=C...,0,4415064

There are four emulators that I know of for the 71B.
* J-F's Emu71/DOS, http://www.jeffcalc.hp41.eu/emu71/
* Christoph Giesselink's Emu71/Win, http://hp.giesselink.com/emu71.htm
* Oliver De Smet's go71b for Android, https://sites.google.com/site/olivier2smet2/home/go71b
* HrastProgrammer's HP-71X for the HP-48GX/49G/49G+/50G, http://www.hrastprogrammer.com/hp71x/index.htm

The first two are free.

[John Cadick]

(03-18-2017 05:34 PM)Dave Frederickson Wrote:  Jean-Francois Garnier's Emu75/DOS was announced two weeks ago.
https://groups.io/g/hp75/message/304?p=C...,0,4415064

There are four emulators that I know of for the 71B.
* J-F's Emu71/DOS, http://www.jeffcalc.hp41.eu/emu71/
* Christoph Giesselink's Emu71/Win, http://hp.giesselink.com/emu71.htm
* Oliver De Smet's go71b for Android, https://sites.google.com/site/olivier2smet2/home/go71b
* HrastProgrammer's HP-71X for the HP-48GX/49G/49G+/50G, http://www.hrastprogrammer.com/hp71x/index.htm

The first two are free.

Thanks, Dave

[charger73]

It takes around 20 seconds on a real HP75C

[J-F Garnier]

(03-18-2017 04:22 PM)Paul Berger (Canada) Wrote:  

(03-18-2017 08:43 AM)J-F Garnier Wrote:  Now, Forth is definitely too cryptic and unstructured for me ...

(03-18-2017 09:57 AM)Garth Wilson Wrote:  That's the way I see C. An absolute disaster.

I don't understand either of these comments, both C and Forth provide plenty of constructs for for structured programming, however neither one of them forces you to use them.

Just my personal opinion on Forth, and to some extend to other stack-based language like RPL.
By unstructured, I'm not referring to programming structures, but to the difficulty to manage expressions with the variables on the stack (PICK, ROLL, etc, this is the cryptic aspect I was referring to), and the difficulty of using local variables.
[personal opinion again] Stack-based approaches are very efficient for machine internal system - the HP85/75 are good examples - but not friendly for user-level programming language. [/personal opinion]

I know C can be cryptic too, but it's easy to write clean code, and some common expressions that can look as cryptic such as:
checksum += *ptr++;
make immediately sense when you are used to.

Globally, I like better to program in assembly language!

J-F

[xerxes]

(03-19-2017 07:17 AM)charger73 Wrote:  It takes around 20 seconds on a real HP75C

Thank you for this interesting test. I've updated the list with your result.

[Paul Berger (Canada)]

(03-19-2017 10:00 AM)J-F Garnier Wrote:  

(03-18-2017 04:22 PM)Paul Berger (Canada) Wrote:  I don't understand either of these comments, both C and Forth provide plenty of constructs for for structured programming, however neither one of them forces you to use them.

Just my personal opinion on Forth, and to some extend to other stack-based language like RPL.
By unstructured, I'm not referring to programming structures, but to the difficulty to manage expressions with the variables on the stack (PICK, ROLL, etc, this is the cryptic aspect I was referring to), and the difficulty of using local variables.
[personal opinion again] Stack-based approaches are very efficient for machine internal system - the HP85/75 are good examples - but not friendly for user-level programming language. [/personal opinion]

I know C can be cryptic too, but it's easy to write clean code, and some common expressions that can look as cryptic such as:
checksum += *ptr++;
make immediately sense when you are used to.

Globally, I like better to program in assembly language!

J-F

I think you can write bad code in any language, but yes your point about the stack is in Forth is true, when I have written Forth I always ended up drawing stack diagrams to keep track of what was where on the stack. I really like C it is pretty much my go to language these days, but I have written assembler too, since I am a hardware person assembler is pretty natural to me. In my only short lived professional programming job, we where using a PL/1 like compiler that output assembler that was used to generate the object code. The target system had nothing like a symbolic debugger, so we had to work with the intermediary assembler listing to debug. Many of the computer science grads on our team had a lot of trouble debugging using an assembler listing while I had no trouble at all.

[hth]

If you find that you need to draw a lot of stack diagrams (apart as top level documentation for a word) and use PICK and ROLL, then maybe you are not really using the language as it is intended.

Forth is a concatenative language that makes it cheap to create new words. The idea is to create small building blocks and combine them together. You should not really have much more than 3 things on the stack that you deal with in a word. This is contrary to C where a function is somewhat expensive to create, so you often end up writing large functions and in extreme (bad) cases even copy-pasting code, rather than factoring out small building blocks.

Forth has problems in my opinion, but that is not related to the stack, it is more caused by the lack of syntax, mode dependent semantics and how the compiler is built into it.

But yes, it is possible to write bad code and make a mess in any language. Some languages makes it easier than others. Trying to use a language as a new syntax for another language one happen to be familiar to, may not always be the best way to approach things.

Håkan