Tony Pavlov via Sdcc-user schreef op 2022-07-22 14:17:
Hello All,
There is a pragma for disabling individual warnings by number. But
seems like no pragma
to restore its original state? pragma save/restore does not affect
warnings?
Hello Tony,
No it doesn't. The mechanism used internally by S
Hello All,
There is a pragma for disabling individual warnings by number. But seems like
no pragma
to restore its original state? pragma save/restore does not affect warnings?
--
Best regards,
Tonymailto:unt...@mail.ru
__
Am 15.07.22 um 17:10 schrieb Maarten Brock:
Ok, so the proper way to 'escape' the # inside a macro definition is by
using another macro.
Yes. Just like other special characters, such as parentheses, etc.
That is fine by me. We should probably put this in the manual even
though it is standar
Hi,
On 7/15/22 17:10, Maarten Brock wrote:
Philipp Klaus Krause schreef op 2022-07-15 16:45:
Since people like form 1, I'd now think we should keep it, but drop
#pragma sdcc_hash. That looks like a better way forward and also
solves the issues.
When this pragma is dropped does that mean it
Philipp Klaus Krause schreef op 2022-07-15 16:45:
Since people like form 1, I'd now think we should keep it, but drop
#pragma sdcc_hash. That looks like a better way forward and also
solves the issues.
When this pragma is dropped does that mean it is no longer possible to
use the # for an im
Since people like form 1, I'd now think we should keep it, but drop
#pragma sdcc_hash. That looks like a better way forward and also
solves the issues.
When this pragma is dropped does that mean it is no longer possible to
use the # for an immediate operand?
You can still use a plain # (
Philipp Klaus Krause schreef op 2022-07-14 21:34:
Am 14.07.22 um 14:46 schrieb Maarten Brock:
Hi Philipp,
Philipp Klaus Krause schreef op 2022-07-14 12:58:
SDCC currently supports two forms of inline assembler:
1:
__asm
asm code here
__endasm;
and
2:
__asm("asm code here");
Does (or will)
I also have rather a lot of inline assembly code in form 1. I have
entire libraries that are almost exclusively naked functions consisting
of only form 1 inline assembly - in fact, mostly done that way
specifically because I wanted to take advantage of C preprocessor macros
within the inline as
Hello Philipp,
Thursday, July 14, 2022, 10:34:13 PM, you wrote:
PKK> Since people like form 1, I'd now think we should keep it, but drop
#pragma sdcc_hash.
PKK> That looks like a better way forward and also solves the issues.
YES!!!
--
Best regards,
Tonymailto:u
Am 14.07.22 um 14:46 schrieb Maarten Brock:
Hi Philipp,
Philipp Klaus Krause schreef op 2022-07-14 12:58:
SDCC currently supports two forms of inline assembler:
1:
__asm
asm code here
__endasm;
and
2:
__asm("asm code here");
Does (or will) this second form also support multiple asm instruc
On Thu, 14 Jul 2022 18:46:46 +0200
Benedikt Freisen wrote:
> What about an additional pre-processing stage that transforms syntax
> variant 1 to variant 2?
Right now you can use __asm at points where it's not a C statement
boundary, or potentially even in C code. I guess it would depend a lot o
What about an additional pre-processing stage that transforms syntax
variant 1 to variant 2?
It could turn
__asm
add a,b
add a,c
__endasm
into
__asm__(
"add a,b\n"
"add a,c\n"
)
Another option would be to rely on a mechanism similar to C++11-style
raw string literals (i.e. R"")
On Thu, 14 Jul 2022 12:58:07 +0200
Philipp Klaus Krause wrote:
> SDCC currently supports two forms of inline assembler:
>
> 1:
> __asm
> asm code here
> __endasm;
>
> and
>
> 2:
> __asm("asm code here");
>
> Form 1 requires some ugly hacks to avoid conflicts in the preprocessor.
> I wonder if
Hi Philipp,
Philipp Klaus Krause schreef op 2022-07-14 12:58:
SDCC currently supports two forms of inline assembler:
1:
__asm
asm code here
__endasm;
and
2:
__asm("asm code here");
Does (or will) this second form also support multiple asm instructions?
AFAIK it doesn't.
And does it not mes
On Thu, Jul 14, 2022 at 8:40 AM Philipp Klaus Krause wrote:
>
> Am 14.07.22 um 13:24 schrieb Ralph Doncaster:
> > It's used in a couple spots in ch554_sdcc
> > https://github.com/Blinkinlabs/ch554_sdcc
> > I've used it in a couple places in CMSIS_DAP
> > https://github.com/nerdralph/ch554_sdcc/tre
Hello Philipp,
Thursday, July 14, 2022, 2:35:46 PM, you wrote:
The main problem is not that this assembler in "form 1" exist.
The problem that this form is very popular. It is used in almost
every project. There is a lot of such code in GBStudio, which is
a very large and extremely popular pro
Am 14.07.22 um 13:24 schrieb Ralph Doncaster:
It's used in a couple spots in ch554_sdcc
https://github.com/Blinkinlabs/ch554_sdcc
I've used it in a couple places in CMSIS_DAP
https://github.com/nerdralph/ch554_sdcc/tree/master/examples/CMSIS_DAP
It's a lot easier to use than gcc-style inline as
Am 14.07.22 um 13:10 schrieb Tony Pavlov via Sdcc-user:
Hello Philipp,
Thursday, July 14, 2022, 1:58:07 PM, you wrote:
NO Please, don't do that!
1. A lot of projects have bug chunks of assembly code in "form 1"
2. Allowing assembly-written naked functions is crucial
3. Separate assembly-on
It's used in a couple spots in ch554_sdcc
https://github.com/Blinkinlabs/ch554_sdcc
I've used it in a couple places in CMSIS_DAP
https://github.com/nerdralph/ch554_sdcc/tree/master/examples/CMSIS_DAP
It's a lot easier to use than gcc-style inline asm. The gcc inline
asm rules with out: in: clobb
Hello Philipp,
Thursday, July 14, 2022, 1:58:07 PM, you wrote:
NO Please, don't do that!
1. A lot of projects have bug chunks of assembly code in "form 1"
2. Allowing assembly-written naked functions is crucial
3. Separate assembly-only sources not always work well, because you loose
the ab
SDCC currently supports two forms of inline assembler:
1:
__asm
asm code here
__endasm;
and
2:
__asm("asm code here");
Form 1 requires some ugly hacks to avoid conflicts in the preprocessor.
I wonder if we could drop those, and maybe even change the keyword in
form 2 to __asm__.
Does anyone
21 matches
Mail list logo
