Beta Testing Volunteer
-
- Posts: 41
- Joined: 31 Jan 2008 14:27
Beta Testing Volunteer
The addition of this forum bodes well!
I would like to be a beta tester. Just let me know when, where, and how.
I would like to be a beta tester. Just let me know when, where, and how.
Beta testing
Hi,
What are the benefits on testing the soft.
I have an easyavr5 with almost all additional boards, and would like to participate in the beta testing of your new products.
I love your boards, and also the idea od your compiler, only at the moment it is not yet stable, and has a lot of problems, to use it professionally.
I would love to see this compiler to be used on avrfreaks !
for that I am willing to help, but there should be at least some benefits.
regards zuran
What are the benefits on testing the soft.
I have an easyavr5 with almost all additional boards, and would like to participate in the beta testing of your new products.
I love your boards, and also the idea od your compiler, only at the moment it is not yet stable, and has a lot of problems, to use it professionally.
I would love to see this compiler to be used on avrfreaks !
for that I am willing to help, but there should be at least some benefits.
regards zuran
Re: Beta testing
Once the beta comes out you will be notified of the testing procedure (and benefits).
Sign me up
I'm ready, send me the info.
- marko.medic
- mikroElektronika team
- Posts: 173
- Joined: 05 Jun 2008 08:07
AVR code generation
I would expect that a new compiler would NOT generate such bad code as the example, below illustrates. This is the result of a statement to print a simple string literal like "hello world". A long series of load immediate and store into RAM instructions is pathetic.
$0069 $E8A1 LDI R26, @?_Local_Text
$006A $E0B0 LDI R27, @@?_Local_Text
$006B $930F PUSH R16
$006C $E60D LDI R16, 109
$006D $930D ST X+, R16
$006E $E609 LDI R16, 105
$006F $930D ST X+, R16
$0070 $E60B LDI R16, 107
$0071 $930D ST X+, R16
$0072 $E702 LDI R16, 114
etc,
etc,
etc for the whole string. And every string literal.
What should generated is storing the string in flash and passing a pointer to that data to a routine to print from flash.
The code generator seems very lame, as a backend to Pascal, Basic and others.
$0069 $E8A1 LDI R26, @?_Local_Text
$006A $E0B0 LDI R27, @@?_Local_Text
$006B $930F PUSH R16
$006C $E60D LDI R16, 109
$006D $930D ST X+, R16
$006E $E609 LDI R16, 105
$006F $930D ST X+, R16
$0070 $E60B LDI R16, 107
$0071 $930D ST X+, R16
$0072 $E702 LDI R16, 114
etc,
etc,
etc for the whole string. And every string literal.
What should generated is storing the string in flash and passing a pointer to that data to a routine to print from flash.
The code generator seems very lame, as a backend to Pascal, Basic and others.
Hi,
Initializations will be improved (both for flash and ram constants), loops will be used for copying data,
But for small chunks of data direct load is more efficient than loop.
We made calculations, so compiler will use optimal solution.
Can you post small code example so we can see the destination of your string?
Initializations will be improved (both for flash and ram constants), loops will be used for copying data,
But for small chunks of data direct load is more efficient than loop.
We made calculations, so compiler will use optimal solution.
Flash or ram will be chosen by string destination, it depends where you will use the string literal.stevech wrote:What should generated is storing the string in flash and passing a pointer to that data to a routine to print from flash.
Can you post small code example so we can see the destination of your string?
This is code from one of your samples. Note the really bad code generation. It's so bad that it is, as we say, rubbish. The string literal should, of course, be compiled as a constant in flash, either as a quoted string or as a byte array, and not a bunch of LDI instructions. The other AVR (and PIC?) compilers pass a pointer to flash to routines such as UART and LCD output (there being both RAM and Flash versions).milan wrote:Hi,
Initializations will be improved (both for flash and ram constants), loops will be used for copying data,
But for small chunks of data direct load is more efficient than loop.
We made calculations, so compiler will use optimal solution.
Flash or ram will be chosen by string destination, it depends where you will use the string literal.stevech wrote:What should generated is storing the string in flash and passing a pointer to that data to a routine to print from flash.
Can you post small code example so we can see the destination of your string?
Code: Select all
usart1_test.abas,48 :: Usart1_Write_Text("mikroElektronika")
$0067 $2FEC MOV R30, R28
$0068 $2FFD MOV R31, R29
$0069 $E8A1 LDI R26, @?_Local_Text
$006A $E0B0 LDI R27, @@?_Local_Text
$006B $930F PUSH R16
$006C $E60D LDI R16, 109
$006D $930D ST X+, R16
$006E $E609 LDI R16, 105
$006F $930D ST X+, R16
$0070 $E60B LDI R16, 107
$0071 $930D ST X+, R16
$0072 $E702 LDI R16, 114
$0073 $930D ST X+, R16
$0074 $E60F LDI R16, 111
$0075 $930D ST X+, R16
$0076 $E405 LDI R16, 69
$0077 $930D ST X+, R16
$0078 $E60C LDI R16, 108
$0079 $930D ST X+, R16
$007A $E605 LDI R16, 101
$007B $930D ST X+, R16
$007C $E60B LDI R16, 107
$007D $930D ST X+, R16
$007E $E704 LDI R16, 116
$007F $930D ST X+, R16
$0080 $E702 LDI R16, 114
$0081 $930D ST X+, R16
$0082 $E60F LDI R16, 111
$0083 $930D ST X+, R16
$0084 $E60E LDI R16, 110
$0085 $930D ST X+, R16
$0086 $E609 LDI R16, 105
$0087 $930D ST X+, R16
$0088 $E60B LDI R16, 107
$0089 $930D ST X+, R16
$008A $E601 LDI R16, 97
$008B $930D ST X+, R16
$008C $E000 LDI R16, 0
$008D $930D ST X+, R16
$008E $910F POP R16
$008F $E8A1 LDI R26, @?_Local_Text
$0090 $E0B0 LDI R27, @@?_Local_Text
$0091 $2E0A MOV R0, R26
$0092 $2E1B MOV R1, R27
$0093 $9212 ST -Z, R1
$0094 $9202 ST -Z, R0
$0095 $2FCE MOV R28, R30
$0096 $2FDF MOV R29, R31
$0097 $D0F7 RCALL usart1_usart1_write_text
Hi,
As I said before:
Initializations will be improved ... loops will be used for copying data ...
This string will be stored in flash and copied to ram at the beginning of the program
Something like this:
This changes are already made, they will be included into the next release of mikroBasic for AVR
As I said before:
Initializations will be improved ... loops will be used for copying data ...
This string will be stored in flash and copied to ram at the beginning of the program
Something like this:
Code: Select all
LDI R30, #?ICSlstr1_LedBlinking+0
LDI R31, hi(#?ICSlstr1_LedBlinking+0)
MOVW R26, R28
LDI R24, #17
CLR R25
L_loopDW:
LPM R0 , Z+
ST X+ , R0
SBIW R24, 1
BRNE L_loopDW
RET
Wrong concept. What you describe is initialization of BSS. In a Harvard architecture chip like the PIC and AVR, one puts constants in flash and use them from flash. You do not copy them to RAM to use them.
Compiler and library should have calls to pass pointers to strings in flash, not copy from flash to RAM then call. (1) wastes time (2) wastes RAM (3) compiler-user lacks control on how RAM is used.
None of the other language compilers, including GCC, Codvision, IAR, Imagecraft, use the approach you outline for MikroElektronika. Some BASIC languages for the AVR too. The good BASIC compilers make it transparent to the user that the constants are in flash and never copied to RAM.
You do not want string constants in RAM. Not at all. RAM is too small and important. For example: a program with many KB of text used for LCD displays. This cannot go in RAM. Will not fit.
the language needs pointers to flash for most all data types. All the compilers I list above do have such pointers. And library routines to take data from flash. Including string compare to constant string, and so on.
Compiler and library should have calls to pass pointers to strings in flash, not copy from flash to RAM then call. (1) wastes time (2) wastes RAM (3) compiler-user lacks control on how RAM is used.
None of the other language compilers, including GCC, Codvision, IAR, Imagecraft, use the approach you outline for MikroElektronika. Some BASIC languages for the AVR too. The good BASIC compilers make it transparent to the user that the constants are in flash and never copied to RAM.
You do not want string constants in RAM. Not at all. RAM is too small and important. For example: a program with many KB of text used for LCD displays. This cannot go in RAM. Will not fit.
the language needs pointers to flash for most all data types. All the compilers I list above do have such pointers. And library routines to take data from flash. Including string compare to constant string, and so on.
-
- Posts: 158
- Joined: 24 May 2008 15:55
- Location: Germany
I am very astonished to hear something like that from Mikroe. The treatment of literals is an elementary thing. The ABC. The other compilers from ME work similar: for every added literal character you get 3 (8051Basic) to 4 bytes (avr,dspic) of code, not spoken of the RAM.stevech wrote:Wrong concept. What you describe is initialization of BSS. In a Harvard architecture chip like the PIC and AVR, one puts constants in flash and use them from flash. You do not copy them to RAM to use them.
Compiler and library should have calls to pass pointers to strings in flash, not copy from flash to RAM then call. (1) wastes time (2) wastes RAM (3) compiler-user lacks control on how RAM is used.
None of the other language compilers, including GCC, Codvision, IAR, Imagecraft, use the approach you outline for MikroElektronika. Some BASIC languages for the AVR too. The good BASIC compilers make it transparent to the user that the constants are in flash and never copied to RAM.
You do not want string constants in RAM. Not at all. RAM is too small and important. For example: a program with many KB of text used for LCD displays. This cannot go in RAM. Will not fit.
the language needs pointers to flash for most all data types. All the compilers I list above do have such pointers. And library routines to take data from flash. Including string compare to constant string, and so on.
Thopas
maybe it's just the individual talking on this forum. The real designers should know better. But gosh, look at the code that the current compiler generates. Wouldn't the PIC, also Harvard-based, have the same problem?
mikroe must think this is just rude complaining.
I think there's not a huge market for an AVR BASIC compiler. ZBasic.net is excellent A++. But it's tied to their hardware.
Alas, perhaps mikroe is too - the compilers being a necessary evil to focus on core business: selling educational boards. Maybe not.
mikroe must think this is just rude complaining.
I think there's not a huge market for an AVR BASIC compiler. ZBasic.net is excellent A++. But it's tied to their hardware.
Alas, perhaps mikroe is too - the compilers being a necessary evil to focus on core business: selling educational boards. Maybe not.
Hi,
As you can see our usart library is written to handle RAM strings. If you do not want that, make your own write text library to handle flash strings. When declaring a flash string do it with
This way your string will be placed in flash and with your usart write text rutine you will be able to print the string directly from flash without storing it to ram first. So, there is a way to do what you want in our compiler.
This issue has nothing to do with our education boards. Furthermore, according to our support, a lot of our user use our compilers with non mE development boards.
It's just that different compilers have different approaches. We have chosen this one, so we would give users an option to put strings both in Flash and RAM. But, we can not cover all options in our libraries. Users should write their own, from time to time. However, we are doing our best to meet user wishes and requirements.
In the incoming release of the compiler, literal strings will be stored to flash/ram according to the parameter you are passing the string to. Also, we may add a check box in compiler settings, which will tell compiler where to put literal strings by default. Personally, I would place an option in compiler settings for every dilemma and user wish we encounter. Believe me, it would be easier for us. But, then, users will probably complain that it is so complicated to adjust all compiler settings and that compiler is not really so easy-to-use...
Users,
Can't live with them. Can't live without them...
As you can see our usart library is written to handle RAM strings. If you do not want that, make your own write text library to handle flash strings. When declaring a flash string do it with
Code: Select all
const flash_string = "mikroelektronika";
This issue has nothing to do with our education boards. Furthermore, according to our support, a lot of our user use our compilers with non mE development boards.
It's just that different compilers have different approaches. We have chosen this one, so we would give users an option to put strings both in Flash and RAM. But, we can not cover all options in our libraries. Users should write their own, from time to time. However, we are doing our best to meet user wishes and requirements.
In the incoming release of the compiler, literal strings will be stored to flash/ram according to the parameter you are passing the string to. Also, we may add a check box in compiler settings, which will tell compiler where to put literal strings by default. Personally, I would place an option in compiler settings for every dilemma and user wish we encounter. Believe me, it would be easier for us. But, then, users will probably complain that it is so complicated to adjust all compiler settings and that compiler is not really so easy-to-use...
Users,
Can't live with them. Can't live without them...
To be comparable with the other compilers, the library or compiler generated wrapper code should have flash and RAM based versions of
PRINT with some or all or no arguments in flash
PRINT formatted with format declaration in flash or RAM
string compare
string assignment
scalars and arrays of constants in flash
structures/records in flash
memory copy
address-of or pointer to flash
PRINT with some or all or no arguments in flash
PRINT formatted with format declaration in flash or RAM
string compare
string assignment
scalars and arrays of constants in flash
structures/records in flash
memory copy
address-of or pointer to flash
-
- Posts: 158
- Joined: 24 May 2008 15:55
- Location: Germany
I think you will not convince ME to change their philosophy. See the advantage: Basic is now a serious language, you have not to learn hundreds of instructions with their parameters (like bascom) but you have to think like C-programmers, somewhat nearer to the machine -stevech wrote:To be comparable with the other compilers, the library or compiler generated wrapper code should have flash and RAM based versions of
PRINT with some or all or no arguments in flash
PRINT formatted with format declaration in flash or RAM
string compare
string assignment
scalars and arrays of constants in flash
structures/records in flash
memory copy
address-of or pointer to flash
so no well-loved print, input, open... .
But a pointer to objects in flash perhaps someone hears that?
Thopas