- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It's very annoying that intel compiler on Windows still fully doesn't support inline asm the way linux build does.
Simplest form with direct symbol reference is still not supported:
generates this error: The direct symbol reference in movzbl is currently unsupported. Access symbols through the asm interface.
How am I supposed to rewrite this with asm interface? Everything I try does not work at all!!
I tried to pass named or regular memory operand, but it does not work with ICL.
generates this error: Syntax error in asm instruction movzbl.
I have different combinations that do not work. For example full mem operand reference:
movzbl coeff_table(%0, %3, 2), %3
I tried all kind of ways, but it seems that I can't get that code working with ICL. In short in that code I load based on the offset stored in register and that offset is calculated by the inline asm code. This code works fine with gcc (on linux or windows and it uses direct symbol reference), I simply try to port it to ICL on windows.
SOO, does it work on ICL or there is no way for me to get it working. Note: this asm code is part of large inline asm block written in at&t asm and i don't think that I have an option to rewrite it in intel style asm.
Simplest form with direct symbol reference is still not supported:
[bash]__asm__ volatile("movzbl coeff_table(%k1), %k1", ...)[/bash]
generates this error: The direct symbol reference in movzbl is currently unsupported. Access symbols through the asm interface.
How am I supposed to rewrite this with asm interface? Everything I try does not work at all!!
I tried to pass named or regular memory operand, but it does not work with ICL.
[bash]__asm__ volatile("movzbl %0(%k1), %k1", ... "m"(coeff_table), ...);[/bash]
generates this error: Syntax error in asm instruction movzbl.
I have different combinations that do not work. For example full mem operand reference:
movzbl coeff_table(%0, %3, 2), %3
I tried all kind of ways, but it seems that I can't get that code working with ICL. In short in that code I load based on the offset stored in register and that offset is calculated by the inline asm code. This code works fine with gcc (on linux or windows and it uses direct symbol reference), I simply try to port it to ICL on windows.
SOO, does it work on ICL or there is no way for me to get it working. Note: this asm code is part of large inline asm block written in at&t asm and i don't think that I have an option to rewrite it in intel style asm.
Link Copied
3 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
On windows, Intel compiler is compatible with Microsoft inline assembly.
On linux Intel compiler is compatible with Gcc inline assembly.
On linux Intel compiler is compatible with Gcc inline assembly.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
well, it does support at&t syntax on windows with some limitation as well (no direct symbol references for example). So, can I do it without direct symbol reference?
Why not make it fully compatible with at&t syntax. In some ways I think it's superior to regular intel style because of all these possible constraints etc.
Why not make it fully compatible with at&t syntax. In some ways I think it's superior to regular intel style because of all these possible constraints etc.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
...i don't think that I have an option to rewrite it in intel style asm...
Personally, I understand you.But, it is Not an easy task to implement a support for some cool feature in a compiler. Look,I fight such things every day and I try to find some workarounds, or another creative solutions.
For example, we're using a 20+ year old Turbo C++ compiler tocreateMS-DOS based 16-bit applications for R&D purposes. Unfortunately, there are several bugs in the compiler and there is NO any possibility Borland will fix it. Period. I was simply forced to findworkarounds for all of them. I admit, it was very frustrating.
Personally, I understand you.But, it is Not an easy task to implement a support for some cool feature in a compiler. Look,I fight such things every day and I try to find some workarounds, or another creative solutions.
For example, we're using a 20+ year old Turbo C++ compiler tocreateMS-DOS based 16-bit applications for R&D purposes. Unfortunately, there are several bugs in the compiler and there is NO any possibility Borland will fix it. Period. I was simply forced to findworkarounds for all of them. I admit, it was very frustrating.

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page