Forum - MCS Electronics

 

FAQFAQ SearchSearch RegisterRegister Log inLog in

Data-Lines in Lib and Inline-Asseembler

 
Post new topic   Reply to topic    www.mcselec.com Forum Index -> BASCOM-AVR
View previous topic :: View next topic  
Author Message
Micha

Bascom Member



Joined: 03 Oct 2006
Posts: 57

germany.gif
PostPosted: Fri Feb 12, 2021 8:53 am    Post subject: Data-Lines in Lib and Inline-Asseembler Reply with quote

Hello

I use a registered Version of Bascom and my interrest is on programming assembler, too.

With Directive
.db
you can store Databytes in Inline-Assembler and Libs.

Is there a way to store Word, Long and String like this?

.dw wordvalue
.dl longvalue
.db "String",0

Or must i use basic-command like Data to do this?

In Lib
*Basic: Data "Hallo" ; for String
*Basic: Data 1%, &h10, $10 ; for numeric

And how can i dim variables and array in assembler?

(BASCOM-AVR version : 2.0.8.3 )
Back to top
View user's profile
laborratte

Bascom Expert



Joined: 27 Jul 2005
Posts: 299
Location: Berlin

germany.gif
PostPosted: Fri Feb 12, 2021 1:44 pm    Post subject: Re: Data-Lines in Lib and Inline-Asseembler Reply with quote

Micha wrote:

Is there a way to store Word, Long and String like this?

.dw wordvalue
.dl longvalue
.db "String",0

no.

Micha wrote:

Or must i use basic-command like Data to do this?

In Lib
*Basic: Data "Hallo" ; for String
*Basic: Data 1%, &h10, $10 ; for numeric

yes.

BASCOM's assembler is not a full featured one like avrasm2. The idea is to support basic in cases where assembler code makes more sense, most likely in terms of size or speed.

Micha wrote:

And how can i dim variables and array in assembler?

Use Basic.

An assembler does not have the concept of "dimming variables". You are loading or storing values into memory cells byte-wise, either directly or with a pointer. That's it. Everything else is up to the programmer.
Back to top
View user's profile
Micha

Bascom Member



Joined: 03 Oct 2006
Posts: 57

germany.gif
PostPosted: Sat Feb 13, 2021 6:00 am    Post subject: Reply with quote

If the compiler does not (yet) support it, it is clear that it does not work.

Thanks for the answer
Back to top
View user's profile
albertsm

Administrator



Joined: 09 Apr 2004
Posts: 5921
Location: Holland

blank.gif
PostPosted: Sat Feb 13, 2021 12:13 pm    Post subject: Reply with quote

for a custom project (6502 to avr) it was required to have .dw and .ds so the next update has this support :
.dw for integer/words
.ds for strings "abc"

no support for single/double/long/dword
but could be added if users like that.

to dim a var is not possible.
but you can access it using {}
lds r24,{myvar}

_________________
Mark
Back to top
View user's profile Visit poster's website
Micha

Bascom Member



Joined: 03 Oct 2006
Posts: 57

germany.gif
PostPosted: Tue Feb 16, 2021 5:44 pm    Post subject: Reply with quote

Hello Mark

That would be great if double, long, single etc. were also supported.

Mitch
Back to top
View user's profile
AdrianJ

Bascom Expert



Joined: 16 Jan 2006
Posts: 2483
Location: Queensland

australia.gif
PostPosted: Tue Feb 16, 2021 11:56 pm    Post subject: Reply with quote

I still cant see the point in assigning high level data in assembler. Assembler has no direct commands for handling any form of data other than bytes. Anything else, you have to code subroutines for. So to get data to feed the subs, you can either just specify lists of bytes as .db statements, or use Bascom data statements to put in the high level numbers, then access them with the lds reg, {myvar} construction, or one of the ld indirect type commands. The whole point of being able to use asm within Bascom is to take advantage of both types of language, not to duplicate stuff which already exists.
_________________
Adrian Jansen
Computer language is a framework for creativity
Back to top
View user's profile Visit poster's website
MWS

Bascom Member



Joined: 22 Aug 2009
Posts: 2262

blank.gif
PostPosted: Wed Feb 17, 2021 1:30 am    Post subject: Reply with quote

Micha wrote:
That would be great if double, long, single etc. were also supported.

Which is rather clueless.
Quote:
... and my interrest is on programming assembler, too.

I don't doubt your interest, but you need to improve your basics first.

As Adrian correctly wrote, for assembler and especially for an 8bit AVR data like single, long a.s.o. are only a certain number of bytes, nothing more.
That's why it makes no sense to create such data types.

If you want to create a bridge between Bascom code and ASM-libs, you have already all the tools at hand.
As then simply declare the function prototypes, dimension the vars and add data to store in flash in Bascom code and acess everything from the lib. This is your only option anyway, as anything else would need to be programmed into the compiler.
Back to top
View user's profile
albertsm

Administrator



Joined: 09 Apr 2004
Posts: 5921
Location: Holland

blank.gif
PostPosted: Wed Feb 17, 2021 9:59 am    Post subject: Reply with quote

i can see usage for long/dword.
but MWS and AdrianJ have good points for single/double.
So before doing that, send some example where it would be required that you can access this data.

_________________
Mark
Back to top
View user's profile Visit poster's website
MWS

Bascom Member



Joined: 22 Aug 2009
Posts: 2262

blank.gif
PostPosted: Wed Feb 17, 2021 1:44 pm    Post subject: Reply with quote

albertsm wrote:
i can see usage for long/dword.

.db, .dw, .dl would be constants (in case .CSEG, .DSEG, a.s.o. aren't implemented), do you intend to create a larger ASM-environment, which would also allow dimensioning of variables?
Kind of this scheme:
Quote:
myVar: .BYTE, 4 ' reserves 4 bytes SRam for variable named myVar

Quote:
send some example

I'd say post it here, so it can be discussed.

I see no big sense behind, trying to transfer only some of the originally dimensioned and declared stuff from a .bas file into the .lib, if still the lib must be called by Bascom code.
And therefore most likely parameters need to be handed over, and as long there is no scheme to completely integrate new commands into the Bascom compiler, there must be a minimum calling stub.

Take the libDEMO.bas from the samples folder, to call Test, the stub is:
Code:
Declare Sub Test(byval X As Byte , Y As Byte)

For not having to mix user's main code with lib-environment code, the libDEMO.bas can be already included with minor modifications by:
Code:
$include "libDEMO.bas

But if you need such a stub-.bas file anyway, then the writer of lib and bas-stub can also use DIM, DATA, CONST, and every other preparation needed by the lib.
Thus your efforts to include constants like .dl are honorable, but wasted time.

I'd love to hear from the TO why exactly he actually feels he can not go this way of an included .bas-file and why he needs the requested extension.
My suspicion in the moment is, that the TO does not know about the already existing possibilities and how to use them.
I may be wrong, but I have often experienced people wishing to have something, without even knowing how to use it.

BUT, this would have some completely different touch, if the .bas-stub can be unified with the .lib to teach the compiler new commands.
Call it .bib maybe Wink

Means a bib would then contain everything, configuration prototype, function prototypes, flash data, dimensioned variables a.s.o.
Including a bib for example:
Quote:
$BIB "myRadio_RDA5807M"

would allow to use the chip's functionality as for example:
Code:
Config  RDA5807M, HighF = 1, PWR = ON, seekISR = OFF
RDA_tune_Up(step = 10)
RDA_tune_Down(step = 10)
RDA_set_Freq(freq = 100.00)

This would be truly a game-changer, include only a bib and get new and completely contained functionality.

I can even think on a scheme, where bib-makers would get the option to protect their tedious work by encryption.
Not to understand me wrong, I like free software, but if some code takes lots of work, I can understand if the writer of same code doesn't want to hand it out for free.
If the charge is reasonable, both parties will win, if it's too expensive and not worth, another one may do it for less or free.

Back to topic, integrating some assembler options, while leaving out true chances will be a waste of your time.
Do you have time to waste?
Back to top
View user's profile
hgrueneis

Bascom Member



Joined: 04 Apr 2009
Posts: 902
Location: A-4786 Brunnenthal

austria.gif
PostPosted: Wed Feb 17, 2021 8:28 pm    Post subject: Reply with quote

Prior to Bascom, I did among others a lot of assembly language, it was the times, but with the Bascom compiler there
is not a lot to gain (maybe in some cases). So, in my opinion, take Bascom or do assembly and be happy, because you spend a year to do the same as Bascom does in ten minutes.
Just my two bits.
Have fun.

Regards
Hubert
Back to top
View user's profile
AdrianJ

Bascom Expert



Joined: 16 Jan 2006
Posts: 2483
Location: Queensland

australia.gif
PostPosted: Wed Feb 17, 2021 11:49 pm    Post subject: Reply with quote

I agree with hgruensis.

In 20+ years of using both ASM and Bascom, I only found a couple of cases where ASM was significanty faster than Bascom. Now that Bascom has direct use of the registers to save intermediate values, rather than save and load from SRAM, even that time saving is mostly moot.

The only time I got significant saving was one case doing very complex bit-twiddling across a big byte array. Anything using 'ordinary' high level structures like words and longs, the savings are negligible. Bascom routines are VERY efficient - thanks to Mark.

If all you want is to save a bit of effort in writing dw instead of db,db then I cant see the point. You could just as easily use something like Visual Basic on a PC to do a 'translation' of any list of variables in any format you like into a list of .db statements, then insert that into the code.

_________________
Adrian Jansen
Computer language is a framework for creativity


Last edited by AdrianJ on Thu Feb 18, 2021 12:01 am; edited 1 time in total
Back to top
View user's profile Visit poster's website
MWS

Bascom Member



Joined: 22 Aug 2009
Posts: 2262

blank.gif
PostPosted: Wed Feb 17, 2021 11:55 pm    Post subject: Reply with quote

hgrueneis wrote:
or do assembly and be happy

The drawback of ASM is, that it is less serviceable and may take more efforts to write.
As we talk about libs and a lib is done only one time, the benefits of optimized speed and smaller flash footprint greatly outweight the drawbacks.
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    www.mcselec.com Forum Index -> BASCOM-AVR All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum