Not able to compile assembly file with latest compiler for c55X 'cl55.exe'

The newer compiler checks for silicon bugs which were unknown when the older compiler was released.  Thus you see ...

Balaganesh V said:

 ERROR! at line 327: [E0800]        Cannot apply a D-unit conditional execute instruction to an Smem read-modify-write that is lock()'d .

It is unlikely your device actually has this silicon bug.  Most such bugs are fixed in recent devices.  You can avoid unnecessary silicon bug checks by using -v to specify the device you use.  For example, this command ...

C:\some\dir\path>cl55 -vOMAP2140 copy_data.asm

... builds clean.  Without -v, all silicon bugs are checked.  With -v, only the bugs relevant to that device are checked.  Use -vlist to see a list of all the device names recognized by -v.

Balaganesh V said:

Also find the stack dump produced by compiler while compiling (cl55.exe.stackdump)

Do you experience this stack dump while building copy_data.asm?  I cannot reproduce that behavior.  Please submit the source file that causes the stack dump.  Also show all the build options exactly as the compiler sees them.

Thanks and regards,

-George

Hi George , 

Thanks for the info . 

My silicon version seems to be -v5510:2.2

Here are the CFLAGS passed to the legacy compiler (V2.2.1) :  -pds232 -pds14 -qq -v5510:2.2 -mp -ml

Now My job is to upgrade the tool chain . 

I tried passing the same to the new compiler (v4.4.1) & faced the error. 

Is there a way to suppress this error & get the file compiled. pls try from your side & share me the CFLAGS.

Note : Iam unaware why -pds232 & -pds14 are passed . 

Also the error displayed is like this ERROR!   at line 327: [E0800] . whether 800(decimal or hex) is the error number ? Whether we can suppress this . 

I tried with new version of  masm55,exe also .

Kindly share your info

Note : The previous stack dump I have shared is not due to this copy_data.asm file . I will check regarding this  & share you later .

Balaganesh V said:

Here are the CFLAGS passed to the legacy compiler (V2.2.1) :  -pds232 -pds14 -qq -v5510:2.2 -mp -ml

I think it makes sense to explain the background for all of these options, so you can make an informed decision about how to handle them.

With regard to -pds232 and -pds14 ...  This tells the compiler to suppress diagnostics with those ID numbers.  Which raises the question: What diagnostics correspond to those ID numbers?  You can look that up in this wiki article.  

With regard to -qq ... This tells to the compiler to be super-quiet about progress messages issued to the console during a build.  All such progress messages are suppressed.  To see what you are missing, try -q instead, or remove it altogether.

With regard to -v5510:2.2 ... This says to build for silicon device C5510 version 2.2.  I do not know how old that device is.  It is at least 10 years old, probably older.  It is very unlikely you use that device now.  You need to determine which device you use now, and change this option to match.  It is possible you use a device that is not recognized by the -v switch.  In that case, you need to determine the version of the CPU core in your device, and then supply the option -vcpu:version .  For example -vcpu:3.3.  I cannot help you determine the version of the CPU core in your C5500 device.  For that, I recommend you start a new thread in the C5000 device forum.  Once you begin using the correct -v option, it is likely that most of your problems will go away.

With regard to -mp ... This is an undocumented option.  I cannot discuss it in a public forum like this.  It is very unlikely you need this option.  I'll contact you privately with further detail.  For other readers of this thread: I guarantee that you never need this option.

With regard to -ml ... This means use large memory model.  It is replaced by the option --memory_model=large.

Thanks and regards,

-George

Thank you for your patience.  I think you have found a bug in the assembler.  It only occurs when building for that old CPU revision.  I filed CODEGEN-1731 in the SDOWP system.  Normally I'd say this bug will be addressed.  But the C5500 compiler tools are no longer under active development.  It is unlikely this bug will get fixed.  The purpose of filing the bug is to have the experts devise a workaround.  I'm pretty sure the workaround will require changing the assembly source.  

Thanks and regards,

-George

Thanks for your reply . 

Kindly share the workaround . It will be very helpful to continue my work. 

Thanks and Regards,

Balaganesh.V