Forum

cgh

Gege34 a écrit : ↑28 avr. 2021 09:08 Sur un ordi ou un téléphone il n'y a pas de mode éxam qui bride les antisèches ou programmes accessibles, sans parler du fait qu'un téléphone tu peux communiquer avec quelqu'un pour avoir les réponses.
Alors qu'une calculatrice en modem éxam c'est un environnement "maitrisé".

C'est quoi le "mode exam" ?

cgh

Concernat l'avenir des calculatrices chez HP, TI, Casio et les autres, on peut aussi se poser la question de l'interet de calculatrices alors que les enfants vont a l'ecole avec des PC portables et des smartphones…
Une calculatrice, c'est un objet de plus a acheter (et c'est souvent cher), a mettre a jour, a charger,...
Un bon petit emu48 ou free42 sur un Android, et hop…
Bon, c'est vrai que la PRIME est plus puissante que les émulateurs/simulateurs, mais pourquoi pas une app HPPRIME sur les stores ?

cgh

kuzja a écrit : ↑20 avr. 2021 21:40
In the first time of the evaluator, only hexadecimal values, symbols and variables were allowed. Hexadecimal value must have a length that must be a multiple of 2, that is: 3, and 003 are invalid but 03 and 0003 are valid.
Actually, this requirement is documented in the manual, so what is surprising is the fact that it is not required in an expression like [+3].

The "obscure" evaluator

No, in fact, when a value is written [opval], the val is read directly. The evaluator does not call itself in this case. The feature to call the evalutaor using the quote sign ' was introduced later, due to my needs for a software I was developing at this time...

I am fully agree with your description about backward compatibility and this is what I expect when I will start the rebuild of the lhTools. At this time, I do not know if I will provide a translation tool or support a "backward" option to legacy syntax.

May the PC1500 be with you.

cgh

Thanks a lot for all the tests and the reports here

In fact, you pointed what is the is badest and most obscure "part" of lhasm: its evaluator !
The development in "way to stay compatible" with older versions of lhdump (and also my sources) and the perpetual enhancements have built a monster that is ambigous and somewhat confusing. This is clearly the part that I need to fully rework. And all choices made were not always good...

I won't change it now, as I expect to release the ultimate and last release 0.8.0 soon.... hmmm... this year... I hope !

The evaluator has inherited from the ancestor of lhasm, named lhbin and provided with the earliest versions. As lhasm is still able to deal with lhbin sources, I keep the current evaluator. Sorry. lhasm was introduced in the 0.4.0 (2014) and has replaced the old lhbin.
In the first time of the evaluator, only hexadecimal values, symbols and variables were allowed. Hexadecimal value must have a length that must be a multiple of 2, that is: 3, and 003 are invalid but 03 and 0003 are valid. In your example, if JR +3 is rejected, JR +03 is accepted. By the way, the following source is correct and produce the expected code:

Code : Tout sélectionner

3	.EQU	03
	JR	+3

As you underlined it, it depends of the context. But this is not the evalutor which is context dependant, but the directives or instructions. So, this why some directives (.ORIGIN, .EQU) and some instructions may accept or reject some contructions that look valid for others.

I will try to describe this by an example of the instruction LDA. There are several syntaxes valid:

Code : Tout sélectionner

LDA rH		: High 8 bits register: B, D, or H (1)
LDA rL		: Low 8 bits register: C, E or L (2)
(3) LDA (R)	: 16-bits register indirection (BD), (DE) or (HL) (3)
(4) LDA F	: Status flags register (4)
LDA (mn)	: 16-bits address indirection (5)
LDA n		: 8 bits immediate value (6)

As lhasm and lhdump share the same table for the description of the instructions (see lh5801.c), the assembler fetches the closest instruction matching the arguments. if you write LDA B, nothing is possible except the load to A with a high 8 bits register (1). If you write LDA 00, nothing is possible except a load to A of the immediate 8 value 00 (6). If you write LDA BC, this more complicated: BC matches a 16-bits register but no instruction is fetchable. So BC is expected to be a 8 bits value and the assembler choses LDA &BC (6). To prevent any ambiguity, I have introduced the values markers: &<hexa>, #<decimal>, @<octal>, $<ascii-char>.

The directive .ORIGIN: is specific as it does not call the evaluator. So it accept only symbols, <hexa 2 or 4 characters length>, &<hexa>, \x<hexa>, #<decimal> and \u<decimal>. I discover that I did a mistake for octal that are read as decimal... The usage of \x, \u and \o is wrong and must be \X, \U and \O; I never see that because but I don't use this syntax...

The evaluator is not called by all directives because some (like .ORIGIN: .ALIGN:) require to have an immediate and non ambigous value that must not change between the passes 1 and 2.

Really great thanks to kuzja for his time spent in testing lhasm

cgh

gege a écrit : ↑15 avr. 2021 18:57 J'ai lancé le Python mais ça ne fait que des erreurs car je suis une quiche et n'y comprends rien.

Nous sommes deux, alors !

cgh

kuzja a écrit : ↑13 avr. 2021 10:27 Thanks a lot! I've downloaded the new version and will give it a try.

Wonderful

Please, send all issues or remarks you will find. It is nice to have feedback from user.

cgh

The lhTools 0.7.8 are now available on the site of repaire.
This version corrects all issues reported by kuzja except these about the documentation (The macros and supported ROM entry points). A dedicated manual will be published later.

Thank you for using the lhTools !

May the PC1500 be with you

cgh

Hello amis des poquettes et collegues sharpistes,

Une mise a jour des lhTools en 0.7.8 avec la correction de toutes les issues remontees par kuzja (sauf celles concernant la documention)

Que le PC1500 soit avec vous !

cgh

Yes ! It is corrected. This was difficult, but it works !

Code : Tout sélectionner

cgh@varvotier:~/work/pc1500/REBUID_JUN2018/lhTools-0.7.8$ cat vnok.s
	.ORIGIN: 40C5
	.CODE
VAR1	.EQU &1234
VAR2	.EQU VAR1
VAR4	.EQU [+10]VAR1
	CALL VAR2
	CALL VAR4
	LD PC,[+06]VAR2
	LDA ([+06]VAR4)
	RET
	.END
cgh@varvotier:~/work/pc1500/REBUID_JUN2018/lhTools-0.7.8$ ./lhasm -T vnok2.s
    . . .
;	lhTools Version 0.7.8 #0
;
;	Source file: vnok2.s
;	lhasm options:
;		-T \
;		vnok2.s

    1
		.ORIGIN:	40C5
    2		.CODE	40C5
    3	40C5	VAR1:	.EQU 1234
    4	40C5	VAR2:	.EQU 1234
    5	40C5	VAR4:	.EQU 1244
    6	40C5	BE 12 34       	CALL	VAR2 
    7	40C8	BE 12 44       	CALL	VAR4 
    8	40CB	BA 12 3A       	LD	PC [+06]VAR2 
    9	40CE	A5 12 4A       	LDA	([+06]VAR4) 
   10	40D1	9A             	RET	
   11	40D2	.END
		;; 40C5	vnok2.s$$._start
		;; 40D2	vnok2.s$$._end
		;; 000D	vnok2.s$$._length

		.SYMBOLS:
	1234	VAR1
	1234	VAR2
	1244	VAR4



Written 13 bytes (40C5:40D2) to vnok2.bin Checksum 0972

The lhTools-0.7.8 are almost ready. I need now to pass all the tests suites. And the documentation to update with issues reported

cgh

kuzja a écrit : ↑09 avr. 2021 22:35 3. .EQU directive accepts most of (perhaps all?) specifiers and operators listed in chapters 2.2 and 2.3 of the manual. But an error is raised if the expression contains a symbol. So you can write
Code : Tout sélectionner
SEPAR	.EQU	$:
OFFSET	.EQU	[+10]&4455
etc., but not
Code : Tout sélectionner
VAR2	.EQU	VAR1
ADR2	.EQU	[+0100]BASE
However, the symbols can be used for immediate values like in

Here, you must use a variable to have the code assembled. The code below does not assemble:

Code : Tout sélectionner

	.ORIGIN: 40C5
	.CODE
VAR1	.EQU &1234
VAR2	.EQU VAR1
VAR4	.EQU [+10]VAR1
	CALL VAR2
	CALL VAR4
	LD PC,[+06]VAR2
	LDA ([+06]VAR4)
	RET
	.END

But the following is accepted correctly:

Code : Tout sélectionner

	.ORIGIN: 40C5
	.CODE
VAR1	.EQU &1234
VAR2	.EQU VAR1
%04v	.EQU VAR1
VAR4	.EQU [+10]%04v
	CALL VAR2
	CALL VAR4
	LD PC,[+06]VAR2
	LDA ([+06]VAR4)
	RET
	.END

cgh

Yo amis des poquettes et collegues sharpistes,

Une petite mise a jour des lhTools en 0.7.7 avec la correction de l'inversion des code ML entre SPV et RPV.

Il y aura bientot une mise a jour suite aux differentes issues reportees par kuzja: see the thread here. Merci a kuzja pour tous ses retours

Que le PC1500 soit avec vous !

cgh

The lhTools 0.7.7 are now available on the site of repaire.
This version corrects the switch of the ML code between SPV and RPV.
A new version 0.7.8 is expected soon when all issues reported by kuzja will be corrected and the lhTools will succesfsully complete their tests suite

Thank you for using the lhTools !

May the PC1500 be with you

cgh

kuzja a écrit : ↑09 avr. 2021 22:35 3. .EQU directive accepts most of (perhaps all?) specifiers and operators listed in chapters 2.2 and 2.3 of the manual. But an error is raised if the expression contains a symbol. So you can write
Code : Tout sélectionner
SEPAR	.EQU	$:
OFFSET	.EQU	[+10]&4455
etc., but not
Code : Tout sélectionner
VAR2	.EQU	VAR1
ADR2	.EQU	[+0100]BASE
However, the symbols can be used for immediate values like in
Code : Tout sélectionner
	LDA (VAR1)
	LD H,[+10]<VAR1
and the compiler correctly understands even an expression like
Code : Tout sélectionner
	LDA (2+ADR)    ; (but not ADR+2)

This depends of your context. A symbol must be defined witth a non ambigous immediate value during the pass 1, and must not differ between the two passes. So
The following works:

Code : Tout sélectionner

	.ORIGIN: 40C5
	.CODE
VAR1	.EQU &1234
VAR2	.EQU VAR1
	CALL VAR2
	RET
	.END

But the following won't because the symbol VAR2 can not be defined due to the inexistece of VAR1 at this time.

Code : Tout sélectionner

	.ORIGIN: 40C5
	.CODE
VAR2	.EQU VAR1
VAR1	.EQU &1234
	CALL VAR2
	RET
	.END

Do you have anorher case when it happens ? If yes, could you share it ?

But it looks like defining a symbol with an expression containing a symbol is not working correctly and the value is wrong... I need to have a look deeply inside the evaluator

cgh

kuzja a écrit : ↑09 avr. 2021 22:35 4. The compiler requires a label to be on a separate line. This is no serious limitation, but if there is an instruction after the label, the compiler silently ignores it, without any warning!

This is a regression due to introduction of the .ARRAY directive, that remove the error if the define is followed by something else than a comment.
The fact that a symbol definition cannot be followied by an instruction is to prevent against recursion when defining a symbol inside a macro. This is a limitation and should be documented.

Waiting for a delivery, here is the patch:

Code : Tout sélectionner

--- lhTools-0.7.7/lhasm.c	2019-03-24 21:22:39.000000000 +0100
+++ lhTools-0.7.8/lhasm.c	2021-04-10 11:36:13.657475367 +0200
@@ -5244,6 +5247,8 @@
           LHASM_ERR( "Unknown array base address %s\n", arg[4+export] );
           v = ((t < b) ? (b - t) : (t - b)) / sz;
         }
+      else if( arg[1+export] && *arg[1+export] != ';' )
+        LHASM_ERR( "Unexpected arguments \"%s\"\n", arg[1+export]);
       else
         v = lhAsmGetPC();
       if( asmpass == 1 )

cgh

kuzja a écrit : ↑09 avr. 2021 22:35 7. The indirect instructions AND (R), AND (mn), OR (R), OR (mn) (and perhaps some other?) should not be followed by a comment, otherwise a warning is raised
--WARNING-- Argument 4; Trailing garbage not processed!
followed by a fatal error "Assembler confused" etc. If there is no comment, these instructions compile correctly.

This is a very insteresting bug !

In fact, AND (R) ; was taken as AND (R),n like the , is not mandatory (due to backward compatibility...). Like the pass 1 of the assembler has tolerance about bad values or symbols not defined, the assembler believes that ; is a symbol and so prepare the code 49 n which is AND (BC),n.
But the pass 2, which expects NO tolerance about bad or undefined values, set the code to AND (BC) that is 09.
Finally, the assembler checks for pointers when assembling the code, it detects that a mnemonic request for 2 bytes (pass 1) and the same mnemonic for 1 byte (pass 2), and so, like this differs, it raises the fatal error about pointer confusion:

Code : Tout sélectionner

a.a line 13: !!!FATAL!!! Assembler confused. END from a.a differs between passes

This is corected by rejecting string starting with ; that marks a comment

The patch below:

Code : Tout sélectionner

--- lhTools-0.7.6p1/lhasm.c	2019-03-24 21:22:39.000000000 +0100
+++ lhTools-0.7.8/lhasm.c	2021-04-10 10:13:59.964344066 +0200
@@ -1399,6 +1399,9 @@
   LHU16 max = 0xFFFF, vs, vv, rel = 0xFFFF, opval = 0, is = 0;
   char symna[80];
 
+  if( !str || (str && *str == ';') )
+    return 0;
+
   if( asmrunmacro && (str && 0 == strncmp( str, "__#", 3 )) )
     {
     if( 1 == sscanf( str + 3, "%hu", &vs ) )

Thanks a lot for reporting this !

Forum

2063 résultats trouvés

Re: HPCC 2021 - Cyrille de Brébisson

Re: HPCC 2021 - Cyrille de Brébisson

Re: Experience with lhTools for PC-1500

Re: Experience with lhTools for PC-1500

Re: Nouvelle version du logiciel pour HP Prime

Re: Experience with lhTools for PC-1500

Re: Experience with lhTools for PC-1500

Re: LhTools - Cross-Assembler/Desassembleur pour PC-1500

Re: Experience with lhTools for PC-1500

Re: Experience with lhTools for PC-1500

Re: LhTools - Cross-Assembler/Desassembleur pour PC-1500

Re: Experience with lhTools for PC-1500

Re: Experience with lhTools for PC-1500

Re: Experience with lhTools for PC-1500

Re: Experience with lhTools for PC-1500