Using DB outside functions

[Edwin Knoppert]

Is there a reliable alternative to the function + label + db statements scenario?

I would like to use !db statement outside any function and obtain the codeptr via a label or other reliable method.
Must be equally reliable as with using a function.

Datalabel1:
!db 123,23

[Steve Hutchesson]

Edwin,

It would be a useful capacity but from memory module level scope is excluded by design.

You can work around it by putting the data you want into a function and on startup call the function and return the address of the data.

FUNCTION whatever() as DWORD

    ! jmp nextlabel
  label:
    db 1,2,3,4, etc ....

  nextlabel:

    FUNCTION = CodePtr(label)

END FUNCTION

[Aslan Babakhanov]

It can be a new PB statement rather than DB outside of all sub/functions. something similar to resource storage.Easy to understand and maintain, rather than using the list of db's spread every very in the code.

DATASTORAGE  AT {DATASEG|CODESEG|PRIVATESEG} "stogareName" | Index = &H01, &H02, CHR$(65,01,05), "mydatastorage"
...
Buffer$    = GETSTORAGECONTENT ("storageName"|Index)
BuffSize& = GETSTORAGESIZE ("storageName"|Index)

I made similar stuff in my projects, as you said, i used to store compressed and encrypted files inside subs/functions

SUB Deflate_DefConfig(BYVAL TargetFile AS STRING)
LOCAL xor_value,i,L AS LONG, OutBuf, InBuf AS STRING,ff AS INTEGER
xor_value = 99
L = 456: inBuf = PEEK$(CODEPTR(buf_lbl), L)
FOR i = 1 TO L
    ASC(inBuf, i) = ASC(inBuf,i) XOR xor_value
NEXT i
Decompress_LZSS (InBuf, OutBuf)
ff=FREEFILE: ERRCLEAR: OPEN TargetFile FOR OUTPUT AS #ff
IF ERR = 0 THEN PRINT #ff, OutBuf;
CLOSE #ff:EXIT SUB
buf_lbl:
! db 102,223,220,220,35,135,159,179,178,186,181,187,169,35,174,189,168,181,179,178,129,209,35,214,143,185,175,175,145,189,178,35
! db 146,185,171,151,185,165,225,237,35,239,209,214,135,142,179,169,168,39,185,174,210,220,149,168,185,177,237,73,225,247,236,238
! db 220,12,1,188,252,220,54,236,210,157,239,202,205,135,152,227,185,175,191,174,181,172,214,156,212,237,67,158,151,140,252,135
...
END SUB

[Michael Mattias]

>>something similar to resource storage.Easy to understand and maintain,

Um, why not resource storage? That's easy to understand and maintain.
Resource script:

// my_res.rc 

101    DB 
BEGIN
   102, 223, 220, 220, 35,
   135, 159, ...
   ...
END
// I forget how you enter decimal vs hex vs octal numeric values. 
// I know you can do byte-at-a-time with hex as in 
//   0X0F, 0x2B, 0x7F,,, etc

Program Code

   ...
   MyString =  ResourceAsString (params) 
' get function here:  
' [url=http://www.powerbasic.com/support/pbforums/showthread.php?t=23674]User-Defined Resource Demo January 26 2003[/url]

  TableAddress = STRPTR(myString) 
  ....

Or, how about String Equates?

$DB_1 = CHR$(102,223,330,35,159...) 

S =  $DB_1
TableAddr = STRPTR(S)

And I suppose DATA statements are out of the question?

Call me a hopeless optimist, but I think I see lots of existing tools here a lot easier to use and understand than would be

DATASTORAGE  AT {DATASEG|CODESEG|PRIVATESEG} "stogareName" | Index = &H01, &H02

MCM

[Steve Hutchesson]

If the data is in very small amounts you would just place it at the end of a function using an EXIT FUNCTION before it but if the data is of any reasonable size going into magabytes use a tool that automates data to DB conversions and put it in its own function.

This works fine for installations were you need to write a binary file to disk and run it. Some of the more recent assemblers have an INCBIN command that will enclose a binary file without requiring notation to do it but I doubt the demand for that type of functionality would justify adding it to a compiler.

It would depend very much on what Edwin wanted to do with the data and how big it was.

[Edwin Knoppert]

Don't worry, there are enough options to solve the issue.
I always used a function and works fine.
I was asking if there is a !DB method without using a function, that's all.

It is slightly easier for code generators to dump a label and some data somewhere in the code.
Currently i combine all the data into a function and use an offset and length to obtain what i need.
Just a little bit less practical to me.

Resources is not what i want here, just DB.

If the compiler is not suitable to make this happen without workarounds, let it be, i am fine.

[Michael Mattias]

>Resources is not what i want here, just DB.

Because I know you are a nice guy, Edwin, I shall (heroically) resist making here any comment containing the phrase "Real Men."

[Aslan Babakhanov]

Is there any limitation of using DB inside the sub/functions in terms of their size? cause they're storing inside the codeseg in flat memory model and there are some compiler limitation on sub/function size...

[Edwin Knoppert]

From experiance it was ~7MB, tested long time ago so i forgot exactly.

[Steve Hutchesson]

Not any longer, since the 32 bit versions of the compiler (what its written in) those days are over.

Just build a test piece on a 16 meg binary file that converted to 68 meg of DB code and built the exe at just over 16 meg.

I have used this technique before when writing installations, create an SFX file, convert it to DB format, write it to disk from the compiled program and run it from the compiled program.

[Edwin Knoppert]

Ah, the 16bit version maybe yes..
Oh well, 68MB of code is good enough (to me)