Pelles C forum

Hello,

Below, the symbol Sample1 is not defined correctly :

level=1

@CatStr(<Sample>,level) CATSTR <test>,level


The output is :

.echo @CatStr(<Sample>,level)

.echo Sample1

"Sample1"
Sample1

The correct assignment should output :

"test1"
test1

Code tested with Poasm Version 12.00.1

Hi Pelle,

Thanks for replying my bug reports

Here is another attempt to solve the issue but this one didn't work too :

level=1

Sample # <level> CATSTR <test>,level

Test.asm(13): error: Invalid use of 'Sample'.
Test.asm(13): fatal error: Invalid use of '#'.

We'll see. What is really needed is a simplified, non-bloated, non-MASM-ish syntax. But since this is 2023, I can.t really see this happening...

Hi Pelle,

Poasm is a very good assembler and it's not bloated. Today, an assembler without a powerful macro engine does not mean much. You did a lot for this tool and in my modest opinion, you should preserve the current state of the macro engine. Modifying radically the macro engine could break a lot of code.  I never asked from you to implement exotic features to Poasm, the forum records are supporting my arguments. We know that maintaining a toolset like Pelles C is not an easy job. My personal opinion is that there is no need to add any new features to Poasm. All what we need is to correct those bugs. The macros can do a lot to support code written with Poasm. What we have so far :

- With thanks to Steve Hutchesson , we can use the master include file of Masm32 with Poasm.
- Converting the import libraries to include files is very easy.
- The Masm32 and Masm64 SDKs can support Poasm again with thanks to Hutch.
- As a long time user of Poasm, I believe that we can create interesting projects.

You are mainly interested in developing the C compiler and the IDE. Naturally, you are right in your choices and I can understand you. All my desire is to cooperate with you and the other forum members to eliminate those bugs. Thanks for your efforts.

Hello,

Trust me, it is bloated... I have the source code...  ;D

You may need a powerful macro engine when only/mostly programming in assembly, but I strongly suspect this is a fairly small group not getting any larger (with any assembler, not just POASM).

When POASM was new (like 2005), there were many wishes for more MASM features and I got carried away. I wish I hadn't because after that I have spent way too many hours, days, sometimes weeks to make old macro examples continue to work with more recent changes/fixes. This is really the problem: almost every change to POASM takes longer than it should, but any attempt at really improving things would take even longer (so not an option).

I will try to fix what you have reported recently, but we are getting closer to a point when it's just not worth the effort...

Hi Pelle,

QuoteYou may need a powerful macro engine when only/mostly programming in assembly, but I strongly suspect this is a fairly small group not getting any larger (with any assembler, not just POASM).

We have here in the forum some members who are doing programming with Poasm and the other assemblers. High level languages are more popular and the assembly language's audience is not so large as you said. The Masm Forum is another venue welcoming coders interested in assembly programming with Poasm, Masm and the Watcom derivative assemblers.

QuoteWhen POASM was new (like 2005), there were many wishes for more MASM features and I got carried away. I wish I hadn't because after that I have spent way too many hours, days, sometimes weeks to make old macro examples continue to work with more recent changes/fixes. This is really the problem: almost every change to POASM takes longer than it should, but any attempt at really improving things would take even longer (so not an option).

I appreciate all your efforts and say thank you for your tools. Maintaining a tool like an assembler is a challenge. I can understand your point of view.

QuoteI will try to fix what you have reported recently, but we are getting closer to a point when it's just not worth the effort...

Thanks for taking in account my reports. What makes Poasm powerful is the full featured 64-bit mode not crippled like ml64 from MS. The 64-bit version of ml ( 64-bit Masm ) does not provide the built-in invoke macro and the other high level constructs.

Hi Vortex, try this in Masm:
  level=111
  @CatStr(<Sample>, level) CATSTR <test>, %level
  % echo Sample111
  level=222
  @CatStr(<Sample>, %level, < equ @CatStr(<test>, %level)>)
  echo Sample222
  .DATA
  Sample222 dd 123
  ; test222 dd 456 ; Error A2056: Symbol already defined: test222
  .CODE
  % echo Sample222
  mov eax, Sample222
  mov ecx, test222

Output:
Sample111
Sample222
test222

Same problem: with echo, you need the % before. The mov ... work, though.

Quote from: Vortex on September 26, 2023, 07:44:48 PMWhat makes Poasm powerful is the full featured 64-bit mode not crippled like ml64 from MS. The 64-bit version of ml ( 64-bit Masm ) does not provide the built-in invoke macro and the other high level constructs.

@Pelle: I can echo that. The Masm64 SDK suffers a lot from being linked to a CrippleWare assembler.

Hi jj2007,

Thanks for the Masm test. Poasm does not use the symbol %. The tool provides a nice alternative, the .ECHO directive instead of % echo.

.ECHO directive (IA32, AMD64)

Purpose:
Displays specified expression(s) on the screen during translation time.

Syntax:
.ECHO [ expression [,] ... ]

Description:
The .ECHO directive evaluates as much as possible of expression and displays it on the screen.

Example:
.ECHO 1 SHL 16, mongo


Hi Pelle,

Testing Poasm Version 13.00.0 :

.386
.model flat,stdcall
option casemap:none

ExitProcess PROTO :DWORD
printf PROTO C :DWORD,:VARARG

includelib  \PellesC\lib\Win\kernel32.lib
includelib  msvcrt.lib

level=1

@CatStr(Sample,level) CATSTR test,level

.echo @CatStr(Sample,level)

.echo Sample1

.data

string db 'Hello world!'

 
.code

start:

    invoke  ExitProcess,0

END start

The output of the .echo statements :

<Sample1>
<test1>
Preserving the symbols < and > like in the original code :

.
.
level=1

@CatStr(<Sample>,level) CATSTR <test>,level

.echo @CatStr(<Sample>,level)

.echo Sample1
.
.
The output :

<Sample1>
<test1>
The issue is solved here but assembler should not insert the symbols < and >

The correct reading should be :

Sample1
test1

The .echo directive display expression(s). Since the internal expression format is totally different in this version, the output is expected (in general) to be a bit different from before.
I'm not convinced this is a bug, but I need some more time to look at it...

Hi Pelle,

No worries. Take your time. Thanks for your efforts, it's a huge job to maintain all the toolset.

I think this is OK as is.

The new (internal) expression format is "richer" in the sense that it can describe more "object" types.
The old generic object file expression format could (barely) handle names and strings, but couldn't really describe the result from f.e. CATSTR (as in this example). The result is more <literal> rhan name or "string".

I see the .echo directive as a debug aid, so displaying the result now as <something> seems more helpful than something or "something" or s-o-m-e-t-h-i-n-g or whatever.