Beta Testing Volunteer

[JerryHRoss]

The addition of this forum bodes well!

I would like to be a beta tester. Just let me know when, where, and how.

[zuran]

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

[zristic]

Once the beta comes out you will be notified of the testing procedure (and benefits).

[woodfold]

I'm ready, send me the info.

[marko.medic]

Hi,

Please read this carefully:
http://www.mikroe.com/forum/viewtopic.php?t=15360

Thanks

[stevech]

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.

[milan]

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.

What should generated is storing the string in flash and passing a pointer to that data to a routine to print from flash.

Flash or ram will be chosen by string destination, it depends where you will use the string literal.

Can you post small code example so we can see the destination of your string?

[stevech]

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.

What should generated is storing the string in flash and passing a pointer to that data to a routine to print from flash.

Flash or ram will be chosen by string destination, it depends where you will use the string literal.

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).

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

[milan]

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:

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

This changes are already made, they will be included into the next release of mikroBasic for AVR

[stevech]

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.

[Thomas.Pahl@t-online.de]

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.

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.
Thopas

[stevech]

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.

[srdjan]

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

Code: Select all

const flash_string = "mikroelektronika";

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...

[stevech]

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

[Thomas.Pahl@t-online.de]

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

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 -
so no well-loved print, input, open... .
But a pointer to objects in flash perhaps someone hears that?
Thopas