Some ideas/improvements for Powerbasic 
Author Message
 Some ideas/improvements for Powerbasic

- I'm build and z80 emulator in pbdll5 ( with much inline asm ) and it
surprized me that the select case function takes 20 bytes/case ( 19 for
the first ). This is much to slow for an emulator, and I therefor added
an array with jump adresses.
Isn't it possible that you guys add a special jump table for fast select
casing?
And, when clockcycles are the most important thing on earth, inline
functions are very easy. Just something like:

  ASM mov eax,10
  Ebx2Eax
  ASM cmp ebx,eax

INLINE SUB Ebx2Eax ' No parameters.
  ( ASM ) mov eax,ebx
END SUB

Rightnow I added several ( that almost 50 ) included files for special
asm functions ( with no labels ).
This makes programming real hard. I get the idea that C++ isn't so bad
afterall.



Thu, 22 Aug 2002 03:00:00 GMT  
 Some ideas/improvements for Powerbasic
Jasper --

As I understand it, the SELECT CASE statement uses floating point math for
all comparisons, since it doesn't know in advance what it will be asked to
evaluate.  The X in SELECT CASE X might be compared to an integer, or a
float, or a function (which could return any numeric data type), or an
equation, or a literal, or ...?   For example, what data type would the
compiler have to use in this example, to compare the integer X% to
something:

SELECT CASE X%
      CASE => VAL(Y$)

There is no possible way for the compiler to anticipate what the Y$ string
will contain -- "2" or "3.1416" -- so there is no possible way to optimize
the code at compile-time.  A floating point comparison must be used.  So X%
will be treated as a float in all other comparisons, too.  True, the
compiler could theoretically check all of the CASE statements to find out
whether or not floats are really needed, but in many cases this becomes
extremely complex and error-prone.  So all of the powerbasic compilers (even
going back to TurboBASIC) do SELECT in this way.

A better tool for a highly-efficient comparison is the multiple IF/THEN
statement.  Each IF/THEN in a PowerBASIC program uses the most efficient
data types that it can, depending on the specifics of what is being
compared, one-to-one.  Even though the left side of multiple-if code will
always be the same...

IF X = 1 THEN

ELSEIF X = 2 THEN

ELSEIF X = 3 THEN

(and so on)

...it will be more efficient -- faster and smaller -- than a SELECT block.
(Unless of course X is a float.)

Since you are talking about writing a Z80 emulator you're probably using
integers from 0-255, so another SUPER-FAST tool that PowerBASIC provides is
ON GOTO.  You will be absolutely astounded how fast it performs, compared to
anything else that the language has to offer.  Or any language for that
matter.  It's amazing!

HTH.

-- Eric



Thu, 22 Aug 2002 03:00:00 GMT  
 Some ideas/improvements for Powerbasic

Quote:

> ON GOTO.  You will be absolutely astounded how fast it performs, compared to
> anything else that the language has to offer.  Or any language for that
> matter.  It's amazing!

I guess you are right, but it will never beat asm.
Say you have made an array with elements 0 to 255 ( all longs ) which point to
the labels, edi contains the pointer to the array and  bl is the opcode input,
you could just do:

  ASM shl ebx,2
  ASM and ebx,1020
  ASM mov edx,es:[edi+ebx]
  ASM jmp edx

Opcode00:
  ASM retn
Opcode01:

Btw, C++ does use this type of select case, but as you said, on goto will do the
job just as fast as C++'s switch();

Still I think that PB needs "Inline" Subs for assembly. PB really lacks here.



Thu, 22 Aug 2002 03:00:00 GMT  
 Some ideas/improvements for Powerbasic

Quote:

>Since you are talking about writing a Z80 emulator you're probably using
>integers from 0-255, so another SUPER-FAST tool that PowerBASIC provides is
>ON GOTO.  You will be absolutely astounded how fast it performs, compared to
>anything else that the language has to offer.  Or any language for that
>matter.  It's amazing!

Ahm.  Though it is considered poor coding technique to use it, COBOL
has had GO TO DEPENDING ON, which does exactly what ON GOTO does,
since 'way before BASIC was born. :-)  I once wrote a compiler/p-code
interpreter in COBOL (only language available), and GO TO DEPENDING ON
was very helpful for decoding p-code opcodes.
--

Sun Valley Systems    http://www.sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."


Sat, 24 Aug 2002 03:00:00 GMT  
 Some ideas/improvements for Powerbasic

Eric,

The compiler could optimize it's code by looking at the values.
For example, if it sees that they are all compared with integer
variables or functions, optimize it for integer. Something like...

SELECT CASE X%
** MOVE DX, [ESI]

    CASE Z%
    ** CMP DX, [EBX]
    ** JE blabla1

    CASE VAL(T$)
    ** CALL StrToInt(T$)
    ** CMP DX, AX
    ** JE blabla2

END SELECT

I think PB could learn allot from the Delphi compiler because it
does all this kind of optimization.

~Meeks~

On Sun, 05 Mar 2000 17:17:49 GMT, "Eric Pearson, Perfect Sync

Quote:

>Jasper --

>As I understand it, the SELECT CASE statement uses floating point math for
>all comparisons, since it doesn't know in advance what it will be asked to
>evaluate.  The X in SELECT CASE X might be compared to an integer, or a
>float, or a function (which could return any numeric data type), or an
>equation, or a literal, or ...?   For example, what data type would the
>compiler have to use in this example, to compare the integer X% to
>something:

>SELECT CASE X%
>      CASE => VAL(Y$)

>There is no possible way for the compiler to anticipate what the Y$ string
>will contain -- "2" or "3.1416" -- so there is no possible way to optimize
>the code at compile-time.  A floating point comparison must be used.  So X%
>will be treated as a float in all other comparisons, too.  True, the
>compiler could theoretically check all of the CASE statements to find out
>whether or not floats are really needed, but in many cases this becomes
>extremely complex and error-prone.  So all of the PowerBASIC compilers (even
>going back to TurboBASIC) do SELECT in this way.

>A better tool for a highly-efficient comparison is the multiple IF/THEN
>statement.  Each IF/THEN in a PowerBASIC program uses the most efficient
>data types that it can, depending on the specifics of what is being
>compared, one-to-one.  Even though the left side of multiple-if code will
>always be the same...

>IF X = 1 THEN

>ELSEIF X = 2 THEN

>ELSEIF X = 3 THEN

>(and so on)

>...it will be more efficient -- faster and smaller -- than a SELECT block.
>(Unless of course X is a float.)

>Since you are talking about writing a Z80 emulator you're probably using
>integers from 0-255, so another SUPER-FAST tool that PowerBASIC provides is
>ON GOTO.  You will be absolutely astounded how fast it performs, compared to
>anything else that the language has to offer.  Or any language for that
>matter.  It's amazing!

>HTH.

>-- Eric



Sat, 24 Aug 2002 03:00:00 GMT  
 Some ideas/improvements for Powerbasic
Meeks,

If we consider the problem with the statement VAL(t$) in *your*
example... the value in T$ could be integer or double precision -
there is no way of the compiler *knowing" what precision T$ will
contain at compile time - it can only ever be a is a runtime
evaluation.  

By using double precision rather than a lower precision or
non-floating point value (ie, single precision, etc) the results of
the CASE comparison are more accurate and dependable.  PowerBASIC
compilers provide other ways of comparing values, and you are free to
use any method that is suitable for your application - ON/GOTO,
IF-ELSE-THEN, etc.

Quote:

>Eric,

>The compiler could optimize it's code by looking at the values.
>For example, if it sees that they are all compared with integer
>variables or functions, optimize it for integer. Something like...

>SELECT CASE X%
>** MOVE DX, [ESI]

>    CASE Z%
>    ** CMP DX, [EBX]
>    ** JE blabla1

>    CASE VAL(T$)
>    ** CALL StrToInt(T$)
>    ** CMP DX, AX
>    ** JE blabla2

>END SELECT

>I think PB could learn allot from the Delphi compiler because it
>does all this kind of optimization.

>~Meeks~

Lance
PowerBASIC Support

-------------------------------------------------------------------------
PowerBASIC, Inc.      | 800-780-7707 Sales | "We put the Power in Basic!"
316 Mid Valley Center | 831-659-8000 Voice | http://www.powerbasic.com



Sun, 25 Aug 2002 03:00:00 GMT  
 Some ideas/improvements for Powerbasic

I know what you mean Lance, but the compiler can optimize the code
according to these guidelines...

1. Find the SELECT CASE optimization method.
It can be either INTEGER, LONG or FLOAT.

2. For each CASE, convert the CASE value to the type found
in the SELECT CASE (if needed) )and use one of the following
optimization code, INTEGER, LONG or FLOAT.

So in ASM it would be this...

SELECT CASE X%   'Use INTEGER optimization.

    CASE Y%
    ' ASM CMP AX, BX

    CASE VAL(T$)
    ' ASM CALL StrToInt
    ' ASM CMP AX, BX

    CASE Y&
    ' ASM CALL LngToInt
    ' ASM CMP AX, BX

END SELECT

SELECT CASE X&   'Use LONG optimization.

    CASE Y%
    ' ASM CALL IntToLng
    ' ASM CMP EAX, EBX

    CASE VAL(T$)
    ' ASM CALL StrToLng
    ' ASM CMP EAX, EBX

    CASE Y&
    ' ASM CMP EAX, EBX

END SELECT

I hope you see my point here. PB really needs to use optimization
for the SELECT CASE statement. Don't it already do that for IF?

-Meeks-


Quote:

>Meeks,

>If we consider the problem with the statement VAL(t$) in *your*
>example... the value in T$ could be integer or double precision -
>there is no way of the compiler *knowing" what precision T$ will
>contain at compile time - it can only ever be a is a runtime
>evaluation.  

>By using double precision rather than a lower precision or
>non-floating point value (ie, single precision, etc) the results of
>the CASE comparison are more accurate and dependable.  PowerBASIC
>compilers provide other ways of comparing values, and you are free to
>use any method that is suitable for your application - ON/GOTO,
>IF-ELSE-THEN, etc.


>>Eric,

>>The compiler could optimize it's code by looking at the values.
>>For example, if it sees that they are all compared with integer
>>variables or functions, optimize it for integer. Something like...

>>SELECT CASE X%
>>** MOVE DX, [ESI]

>>    CASE Z%
>>    ** CMP DX, [EBX]
>>    ** JE blabla1

>>    CASE VAL(T$)
>>    ** CALL StrToInt(T$)
>>    ** CMP DX, AX
>>    ** JE blabla2

>>END SELECT

>>I think PB could learn allot from the Delphi compiler because it
>>does all this kind of optimization.

>>~Meeks~

>Lance
>PowerBASIC Support

>-------------------------------------------------------------------------
>PowerBASIC, Inc.      | 800-780-7707 Sales | "We put the Power in Basic!"
>316 Mid Valley Center | 831-659-8000 Voice | http://www.powerbasic.com




Mon, 26 Aug 2002 03:00:00 GMT  
 Some ideas/improvements for Powerbasic
Meeks --

Quote:
> SELECT CASE X%   'Use INTEGER optimization.

>     CASE Y%
>     ' ASM CMP AX, BX

>     CASE VAL(T$)
>     ' ASM CALL StrToInt
>     ' ASM CMP AX, BX

>     CASE Y&
>     ' ASM CALL LngToInt
>     ' ASM CMP AX, BX

The problem with that is that you can't use integers to compare an integer and
a long (Y&) unless you're willing to say that Y& can never be greater than
32k.  Only identical data types can be compared, so if the block above was
optimized for integers, what would happen if Y& was >32k and it was "forced"
into an integer?

Another example... What if the SELECT line was a DWORD and one of the CASEs
was an integer that could contain a negative value?  Then you'd have to
convert everything to double-precision anyway, in order to accomodate every
possible value.

And another... What if the SELECT line was an integer, and one of the CASEs
was the sum of two integers like X%+Y%?  Since the CASE could evaluate to

Quote:
>32k, which data type do you choose?  DWORD?  Make it more than a simple sum

and everything gets really crazy.   The optimizations can get very, very
complex, and you'd probably end up using doubles.

At the very most, the compiler could use a "greatest common denominator"
strategy that wasn't based on (just) the SELECT line.  Even so, if the SELECT
block was optimized to use the most efficient possible type given the CASEs,
it would (under most circumstances) not be as efficient as using
individually-optimized IF/THEN statements.  SELECT is inherently inefficient
because it requires all of the values to be converted to a single data type,
and while you can improve things by using the "optiimum" type, IF/THEN will
almost always be more "optimizable".

PowerBASIC's current strategy of using floats for all SELECT CASE operations
is (IMO) the best strategy simply because it always works!  The programmer
doesn't have to worry about any "gotchas" at all.

-- Eric



Mon, 26 Aug 2002 03:00:00 GMT  
 Some ideas/improvements for Powerbasic

You have a point Lance. But here's a good working rule...

1...
If the SELECT is not of the same type as the CASE then convert* the
value of SELECT or CASE to the one in the CASE or SELECT and do
the comparison.

*
The conversion rule would be that the conversion would be on the
greatest type* of the comparison. Say you compare an INTEGER
with a DWORD, then convert the INTEGER to the DWORD and
do the comparison. The order would be...

type = (1 to 6)...
1. BYTE
2. INTEGER
3. LONG
4. DWORD
5. QWORD
6. FLOAT (VAL is a float)

if SELECT type is < CASE type then
    convert SELECT
else
    convert CASE
end if

...and any equation to be calculated at runtime would evaluate
to the highest type (1 to 6).

INTEGER + LONG = LONG
VAL + INTEGER = FLOAT
DWORD + FLOAT = FLOAT
DWORD + INTEGER = DWORD

That would not require allot of work to do this optimization because
it's based on a very simple rule. The big one wins (1 to 6 above)

If 2 integer are added up and becomes a long, then overflow error
would be generated right?

-Meeks-

<snip>

Quote:
>The problem with that is that you can't use integers to compare an integer and
>a long (Y&) unless you're willing to say that Y& can never be greater than
>32k.  Only identical data types can be compared, so if the block above was
>optimized for integers, what would happen if Y& was >32k and it was "forced"
>into an integer?

>Another example... What if the SELECT line was a DWORD and one of the CASEs
>was an integer that could contain a negative value?  Then you'd have to
>convert everything to double-precision anyway, in order to accomodate every
>possible value.

>And another... What if the SELECT line was an integer, and one of the CASEs
>was the sum of two integers like X%+Y%?  Since the CASE could evaluate to
>>32k, which data type do you choose?  DWORD?  Make it more than a simple sum
>and everything gets really crazy.   The optimizations can get very, very
>complex, and you'd probably end up using doubles.

>At the very most, the compiler could use a "greatest common denominator"
>strategy that wasn't based on (just) the SELECT line.  Even so, if the SELECT
>block was optimized to use the most efficient possible type given the CASEs,
>it would (under most circumstances) not be as efficient as using
>individually-optimized IF/THEN statements.  SELECT is inherently inefficient
>because it requires all of the values to be converted to a single data type,
>and while you can improve things by using the "optiimum" type, IF/THEN will
>almost always be more "optimizable".

>PowerBASIC's current strategy of using floats for all SELECT CASE operations
>is (IMO) the best strategy simply because it always works!  The programmer
>doesn't have to worry about any "gotchas" at all.

>-- Eric



Mon, 26 Aug 2002 03:00:00 GMT  
 Some ideas/improvements for Powerbasic

Why not just allow the programmer to force the type of select, which would
be a compile time issue?

SELECT CASE expression AS LONG
CASE whatever2
CASE whatever2
CASE ELSE
END SELECT

Since most error handling has been passed back to the programmer in the
Windows products, it would be the programmer's problem (and rightfully so)
if the data type of the whatevers did not match the expression. In fact,
with this kind of explicit typing, compile and runtime errors should be
generated if the whatevers are not the same type as defined for expression.

Now you have the best of both worlds:

-- without the AS TYPE clause, works as currently implemented

-- with the AS TYPE clause, imposes a minute compile time penalty, and
allows the runtime performance improvements, and puts the choice in the
programmer's hands

-- provides a cleaner syntax (and maintainability is a big issue, so clean
syntax is a GOOD thing) than ON GOTO or IF/ELSEIF while maintaining the
performance advantage

ON GOTO is cool, but it assume sequential numbers, whereas SELECT allows any
numbers. The true advantage of IF/ELSEIF is for implementing complex logic
that is not based on a single value. Using it as a high performance SELECT
is a bastardization and does not produce clean code.

My $0.02



Mon, 26 Aug 2002 03:00:00 GMT  
 Some ideas/improvements for Powerbasic

Quote:
> ON GOTO is cool, but it assume sequential numbers, whereas SELECT allows
any
> numbers. The true advantage of IF/ELSEIF is for implementing complex logic
> that is not based on a single value. Using it as a high performance SELECT
> is a bastardization and does not produce clean code.

I'll restate this before someone else corrects me. SELECT is not limited to
numbers -- yes, I knew that. But ON GOTO is, and number-based branching is
what we were discussing.

ON GOTO requires sequential numbers in the BYTE range (0-255). Furthermore,
the sequence must start with 1 (0 is a special case). Therefore, if you
conditionals are NOT in nice sequential order, or are not in the BYTE range,
you must code some gymnastics to map the values. Hence the value of
SELECT -- the conditionals can be values in any order or range.

As I said, while IF/ELSEIF can be used to handle the situation while also
providing improved performance, it does not create code that is a clean and
readable as a SELECT.

The more I think about it, the more I like the idea of a typed SELECT.



Mon, 26 Aug 2002 03:00:00 GMT  
 Some ideas/improvements for Powerbasic
You seem to be missing the point:

If we go though all of your "rules" to evaluate VAL(T$) at runtime,
then by the time the compiler has tried to check what variable class
the numeric representation of the value in T$ is, we've already taken
longer than converting to double precision anyway, and based on your
rules, we may still have to convert to double precision before
actually performing the comparison.

In addition, your "rules" would mean that we may need to translate the
SELECT CASE value in addition to the CASE value...  

Now, where is the increased efficiency?

In practice, SELECT CASE gets tyhe job done and it works.  If you need
better performance in your code, then PB provides other ways to
achieve your goals:

1. IF THEN
2. ON GOTO
3. Inline Assembler
4. ...

Quote:

>You have a point Lance. But here's a good working rule...

>1...
>If the SELECT is not of the same type as the CASE then convert* the
>value of SELECT or CASE to the one in the CASE or SELECT and do
>the comparison.

>*
>The conversion rule would be that the conversion would be on the
>greatest type* of the comparison. Say you compare an INTEGER
>with a DWORD, then convert the INTEGER to the DWORD and
>do the comparison. The order would be...

>type = (1 to 6)...
>1. BYTE
>2. INTEGER
>3. LONG
>4. DWORD
>5. QWORD
>6. FLOAT (VAL is a float)

>if SELECT type is < CASE type then
>    convert SELECT
>else
>    convert CASE
>end if

>...and any equation to be calculated at runtime would evaluate
>to the highest type (1 to 6).

>INTEGER + LONG = LONG
>VAL + INTEGER = FLOAT
>DWORD + FLOAT = FLOAT
>DWORD + INTEGER = DWORD

>That would not require allot of work to do this optimization because
>it's based on a very simple rule. The big one wins (1 to 6 above)

>If 2 integer are added up and becomes a long, then overflow error
>would be generated right?

>-Meeks-

><snip>
>>The problem with that is that you can't use integers to compare an integer and
>>a long (Y&) unless you're willing to say that Y& can never be greater than
>>32k.  Only identical data types can be compared, so if the block above was
>>optimized for integers, what would happen if Y& was >32k and it was "forced"
>>into an integer?

>>Another example... What if the SELECT line was a DWORD and one of the CASEs
>>was an integer that could contain a negative value?  Then you'd have to
>>convert everything to double-precision anyway, in order to accomodate every
>>possible value.

>>And another... What if the SELECT line was an integer, and one of the CASEs
>>was the sum of two integers like X%+Y%?  Since the CASE could evaluate to
>>>32k, which data type do you choose?  DWORD?  Make it more than a simple sum
>>and everything gets really crazy.   The optimizations can get very, very
>>complex, and you'd probably end up using doubles.

>>At the very most, the compiler could use a "greatest common denominator"
>>strategy that wasn't based on (just) the SELECT line.  Even so, if the SELECT
>>block was optimized to use the most efficient possible type given the CASEs,
>>it would (under most circumstances) not be as efficient as using
>>individually-optimized IF/THEN statements.  SELECT is inherently inefficient
>>because it requires all of the values to be converted to a single data type,
>>and while you can improve things by using the "optiimum" type, IF/THEN will
>>almost always be more "optimizable".

>>PowerBASIC's current strategy of using floats for all SELECT CASE operations
>>is (IMO) the best strategy simply because it always works!  The programmer
>>doesn't have to worry about any "gotchas" at all.

>>-- Eric

Lance
PowerBASIC Support

-------------------------------------------------------------------------
PowerBASIC, Inc.      | 800-780-7707 Sales | "We put the Power in Basic!"
316 Mid Valley Center | 831-659-8000 Voice | http://www.powerbasic.com



Tue, 27 Aug 2002 03:00:00 GMT  
 Some ideas/improvements for Powerbasic


Quote:

> Why not just allow the programmer to force the type of select, which
would
> be a compile time issue?

> SELECT CASE expression AS LONG
> CASE whatever2
> CASE whatever2
> CASE ELSE
> END SELECT

> Since most error handling has been passed back to the programmer in the
> Windows products, it would be the programmer's problem (and rightfully
so)
> if the data type of the whatevers did not match the expression. In fact,
> with this kind of explicit typing, compile and runtime errors should be
> generated if the whatevers are not the same type as defined for

expression.

Agreed. This would provide a reasonable solution. Another option
is that the Select Case "variable" determines the typing of the
entire select, as the original author proposes. IFF the variable
attached to the select is INTEGER, then all the evaluations should
be done as integer. IFF the variable attached is String, then the
evaluations should all be done as String, IFF the variable is
actually an expression, then the current double precision rules
could continue to apply.

- Show quoted text -

Quote:

> Now you have the best of both worlds:

> -- without the AS TYPE clause, works as currently implemented

> -- with the AS TYPE clause, imposes a minute compile time penalty, and
> allows the runtime performance improvements, and puts the choice in the
> programmer's hands

> -- provides a cleaner syntax (and maintainability is a big issue, so
clean
> syntax is a GOOD thing) than ON GOTO or IF/ELSEIF while maintaining the
> performance advantage

> ON GOTO is cool, but it assume sequential numbers, whereas SELECT allows
any
> numbers. The true advantage of IF/ELSEIF is for implementing complex
logic
> that is not based on a single value. Using it as a high performance
SELECT
> is a bastardization and does not produce clean code.

And for DECADES, the educational and "professional programmer" communities
have been insisting that any
form of GOTO is "BAD" programming.

Quote:
> My $0.02

Adding my $0.02 makes the total value of this message $0.04

J. M. Good



Tue, 27 Aug 2002 03:00:00 GMT  
 Some ideas/improvements for Powerbasic

[about optimization of SELECT CASE:]

Quote:
>If we go though all of your "rules" to evaluate VAL(T$) at runtime,
>then by the time the compiler has tried to check what variable class
>the numeric representation of the value in T$ is

Let's exclude "case" with calculated values. If the compiler detects
that all CASE statements are constants, then shurely it must be possible
to settle on the smallest common super-datatype?

        Select case X%
          case 0 to 31
            ...
          case 127
            ...
          case else
            ...
        end select

You MUST be able to determine that INTEGER would be a good choice of
data representation, for this particular example?

--
        Bart.



Tue, 27 Aug 2002 03:00:00 GMT  
 Some ideas/improvements for Powerbasic

Quote:

>And for DECADES, the educational and "professional programmer" communities
>have been insisting that any
>form of GOTO is "BAD" programming.

Dont read everything you believe! (g)   These types of comments are
usually from people who are unaware that modern Basic compilers are no
longer for the poor relations of C/C++ programmers.  

As most folks here know, the careful application of a GOTO or two is
nothing to be sneered at...  certainly not by *real* (professional)
programmers writing *real* applications! (smile).  

Quote:
>> My $0.02
>Adding my $0.02 makes the total value of this message $0.04

Better upgrade that to $0.06.

Lance
PowerBASIC Support

-------------------------------------------------------------------------
PowerBASIC, Inc.      | 800-780-7707 Sales | "We put the Power in Basic!"
316 Mid Valley Center | 831-659-8000 Voice | http://www.powerbasic.com



Tue, 27 Aug 2002 03:00:00 GMT  
 
 [ 34 post ]  Go to page: [1] [2] [3]

 Relevant Pages 

1. PEP 267 improvement idea (fwd)

2. looking for powerbasic 3.x

3. PowerBASIC at Davar Web Site

4. PowerBASIC at Davar Web Site

5. PowerBASIC at Davar Web Site

6. PowerBASIC at Davar Web Site

7. New PowerBASIC compilers!

8. PowerBASIC at Davar Web Site

9. PowerBASIC at Davar Web Site

10. PowerBasic and FreeDOS32

11. Compiling an OBJ module into a basic program in version 3.5 PowerBasic for DOS

12. converting to powerbasic

 

 
Powered by phpBB® Forum Software