![[logo]](/img/veripool_small.png)
Issue #283
Verilog preprocessor does not expand macros in argument
| Status: | Closed | Start date: | 09/16/2010 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | Wilson Snyder | % Done: | 0% |
|
| Category: | - | |||
| Target version: | - |
Description
Hi, I am trying to expand the following macro definition:
`define FRAME_TYPE sonet `define JOIN(_arg1, __arg2) __arg1``_arg2 `define XACTION `JOIN
`XACTION
I would expect the last `XACTION call expanding to sonet_frame. However output of preprocessor shows `FRAME_TYPE_frame. Parsing this in VCS produces the expected output: sonet_frame
As the macro is expanded, the arguments are fully expanded before the next expansion, I would expect the following steps:
`XACTION `JOIN `JOIN cxtf``_frame cxtf_frame
History
Updated by Usha Priyadharshini over 1 year ago
Updating since the code segment does not show up as expected:
Trying to expand the following macro definition:
`define FRAME_TYPE sonet `define JOIN(__arg1, __arg2) __arg1``__arg2 `define XACTION `JOIN(`FRAME_TYPE, _frame) `XACTION
I would expect the last `XACTION call expanding to sonet_frame. However output of preprocessor shows `FRAME_TYPE_frame. Parsing this in VCS produces the expected output: sonet_frame.
As the macro is expanded, the arguments are fully expanded before the next expansion, I would expect the following steps:
`XACTION `JOIN(`FRAME_TYPE, _frame) `JOIN(sonet, _frame) sonet``_frame sonet_frame
Updated by Wilson Snyder over 1 year ago
- Status changed from New to Assigned
- Assignee set to Wilson Snyder
Unfortunately the specification doesn't clearly specify the order of expansion, so the results depends on the simulator. I think you're interpretation makes more sense, but let me try more simulators to see what the majority believe.
Updated by Wilson Snyder over 1 year ago
Misspoke above, the order of expansion is specified, just not when `` is done during expansion.
Updated by Wilson Snyder over 1 year ago
- Status changed from Assigned to Resolved
First, I did some research, and only 3 of four simulators surveyed support this ordering. If you want to be maximally compliant, you may not want to do that.
However, majority rules. I further discovered that the majority believes:
`define QA_b qindirect `define Q1 `QA``_b //-> qindirect `define QA a //-> a_b
which is amazing, as I just wrote a paper that discovered a ton of odd stuff, but missed this!
Anyhow, fixed in git, for 3.303.
Also available in: Atom