Don't work at all !

[Richard Ferguson]

I was woundering if anyone can help to get this to work in PB ?
As I can not.
DIM M AS STRING
M$ = "Hello World!"

! push ds
! mov ax,@data
! mov ds,ax

! mov ah,9
! mov dx,offset M$
! int 21h

! mov ax,4C00h
! int 21h

This is just tp print the message to the screen.

Thanks in advance
Richard Ferguson

------------------


------------------

[Adam J. Drake]

What version of PB are you in? (CC, DOS, WIN)?

------------------

[Michael Mattias]

PRINT

[Richard Ferguson]

DOS PB 3.2

Richard Ferguson

------------------

[Adam J. Drake]

The reply I posted in Console Compiler obviously does not apply to this as I thought it was PB CC you were in.

However, Michael's right. For screen output, most of the time, you will not see a speed problem using locate/print...

------------------

[Richard Ferguson]

I am really trying to do it in there in Assembly to first see if
I can do it and to try and find out the actual limits of this
program (compiler).
I just need to know how to get this code or something similar
up and running!

Richard Ferguson

------------------

[Richard Ferguson]

I must first learn the boundaries that I am working in before I
can start to push this language to it's actual limits! I will
eventuall get it to work even if I have to use TASM or MASM
to write subs to do this!

Richard Ferguson

------------------

[Adam J. Drake]

richard, at this point, i can't help since it's in pbdos (i've never programmed there).

however, from a very knowledgeable fellow named lance edmonds, at url: http://www.powerbasic.com/support/pb...ead.php?t=1066

the print statement writes directly into video memory, so it's pretty fast. is there a specific reason you want to drop down to the dos interrupt level to do this? your asm code might be fast, but print will likely be faster.

if an allowance for redirection is the main consideration, then use stdout instead (since that will be routed through dos).

pb dos/win really does a very good job in generating tight fast compiled code, so a lot of times (at least through experiementation), coding in pb inline asm rather than straight pb has proved to not give any performance gains, and at times, slow it down.

------------------


[this message has been edited by adam j. drake (edited january 06, 2005).]

[Richard Ferguson]

I am from the old school where when we wrote programs I had
control over all of the segment areas in my programs so that
I could manipulate them as I wish or (DEEM) necessary! I am
atempting to see if this Power Basic compiler is truely OPEN
as far as from the programmers perspective! Assembly should
not be restricted in any way ,and if this compiler will let
me do what I whish when I wish then this is something that I
will enjoy programming in, so in a way this is just mearley
a very simple test of the compilers capabilities as far as from
an ASM programmers point of view!

Richard Ferguson

------------------

[Adam J. Drake]

Well, like I said, inline ASM at times has proved to be slower than the straight PB equivalent.

And, it's inline, not full ASM.

Beyond that, like I said, I can't be of much help as I've never programmed in PBDOS, and it's been a little too long since DOS ASM.



------------------

[Richard Ferguson]

I will keep trying to get this to work fo the rest of today and
then I will post on my site that PB is NOT the programming
language to go to if you are wishing to program in
Basic/Assembly.

Richard Ferguson

------------------

[Michael Mattias]

>Assembly should not be restricted in any way ...test of the compilers capabilities as far as from an ASM programmers point of view!

NEWS FLASH

Carmel CA, approx 1988: Spectra Publishing Inc. announces PowerBASIC, a BASIC-language compiler....

[Adam J. Drake]

I will keep trying to get this to work fo the rest of today and
then I will post on my site that PB is NOT the programming
language to go to if you are wishing to program in
Basic/Assembly.

PB is NOT the programming language to go to if you are wishing to program in ASM only.

Basic, most definitely. With the capability for inline ASM.

------------------

[Bob Zale]

Well, Richard, the problem is in your code. I'm afraid it's in error.

That said, I must tell you that the PowerBASIC PRINT statement will actually execute substantially faster than using the BIOS interrupts. If speed and accuracy is your goal, this particular effort is assured to fail.

However, if it's just an exercise to see if you can write this code successfully, I surely understand. And, in that case, I'll be happy to have one of our engineers show you the problem and walk you through the correct coding.

There's just one small problem. I can't locate any record that you've ever purchased a copy of PowerBASIC. So, if you'll just email your purchase details (and serial number) to [email protected] they'll get you registered today! Then we can have an engineer get it working for you at once.

I hope we'll hear from you soon!

Regards,

Bob Zale
PowerBASIC Inc.


------------------

[Hans Ruegg]

Hi Richard,

I am using PBDOS 3.5, but I assume there is no significant
difference to 3.2.

I would suggest the problem is in this line:

! mov dx, offset m$

In order to get a pointer to string data, you would have to use
STRPTR and STRSEG (see the docs or the in-built help system).
So you would store the segment and pointer to your string data
in two integer variables and then use these variables in your
assembler code. (This means you don't have control over where
exactly in memory your string will be stored; but you can retrieve
the actual pointers with STRSEG and STRPTR.)
What I am not sure about, is how fixed or not these pointers are
(i.e. if they may change if you change the string's content);
possibly you would have to call STRSEG and STRPTR again after
each change made to the string's content.

Hope this helps a little.

Regards,

Hans Ruegg

PS: Also, if I remember correctly, Int 21h Function 9 requires
the string to end with a dollar sign ($).

PPS: Instead of using inline assembly, you can also link external
*.obj modules into your program.

------------------

[Paul Dixon]

Richard,
when you use a string variable in asm you don't get the variable, you get a string handle which you then need to use to look up the details of the string.
This can be done in ASM using the built in function GeetStrLoc (you must include the DECLARE to access it).
It can be done in BASIC using STRPTR and STRSEG to put the data into non-string variables which can then be accessed directly in ASM/

Paul.

'define the string
dim M as string
m="Hello world!$"
 
 
'version 1 use BASIC
print m
 
 
'version 2 use the built in function to get the string details from ASM
Declare function GetStrLoc(byval allochandle%) as long
 
!push ds	;save DS
!mov ax,m 	;get the string handle to ax
!push ax        ;push it on the stack
!call getstrloc ;this internal funtion returns the string location
		'on return, dx= segment, ax=offset, cx=string length
!mov ds,dx	;get string segment into DS
!mov dx,ax	;get string offset into dx
 
!mov ah,9       ;print use int 21h
!int &h21
 
!pop ds		;restore DS
 
 
 
'version 3 get the string address using BASIC statements first (the way I usually do it)
offs%=strptr(m)	'get the offset of the string
sg%=strseg(m)	'get the segment of the string
 
!push ds	;save DS
!mov dx,offs%	;get offset to DX
!mov ds,sg%	;get segment to DS
 
!mov ah,9
!int &h21	;call int 21h
 
!pop ds		;restore DS

------------------

[Richard Ferguson]

quote:
However, if it's just an exercise to see if you can write this
code successfully, I surely understand. And, in that case,
I'll be happy to have one of our engineers show you the problem
and walk you through the correct coding.

Borrowed the program from a friend to try it out to see if it
actually works! After all if it does not perform to my
satisfaction I will deleate it and not purchach it in any way
shape or form!

Testing all kinds of programming compilers and assemblers is
what I do any way!

But, if you prefer that I just deleate it I will at once
before I have finished my testing?

By the way Hans I have tried it the way that you suguested with
the standard way I was about to link in an object file that I
have created to test this out!

Richard Ferguson

------------------

[Richard Ferguson]

Thanks Paul that was very insitefull I am now getting a very
clear picture as to how the compiler was designed and written.
Now all I have to do is perform a few more simple tests that will
put the compiler through a series of critical tests and then it
should answer rhe questions that I have about it and I can then
deleate this program and all files except the source and test
results and move onto another compiler and or assembler/
interpretor!

Have a nice day all

Richard Ferguson

------------------

[Brad D Byrne]

So, Richard

you have a compiler/interpreter comparison/evaluation site?

what's the name of it?

Thanks, Brad

------------------
Washington DC Area
Borje's "Poff's" is likely the BEST tool for learning PB.. http://www.tolkenxp.com/pb
And a few PBTool's & Beginner Help:http://sweetheartgames.com/PBTools/JumpStart.html

[This message has been edited by Brad D Byrne (edited January 06, 2005).]

[Donald Darden]

You are correct, Hans. The automatic garbage collecting and
allocating of new string space means that strings can move
around in memory. STRPTR will tell you where the string is
located currently, but if you assign that to a variable, that
variable's reference but may not be valid later. So you should
re-reference it again before using it again.

VARPTR is also useful because it points to the variable, and
the variable always has the current location and size of the
associated string - in fact, this is where STRPTR comes to get
the location of the string. Note that when using TYPE structures,
The VARPTR serves in place of STRPTR, since there is no separate
variable reference, thus you lack one level of redirection.

The inline assembler can be quite useful, and when coupled with
PowerBASIC's ability to perform all manner of string, structure,
logical, and mathematical manipulations, gives you the best of
both worlds. PowerBasic is such a clean language that time trials
to try and prove that ASM is always faster, often do not.

I think that it is a poor judgement call on your part to claim
to be a elitist ASM programmer and condemn a product that made
no pretense at being a pure assembler environment. I've written
tons of assembler code over the years, and would be just as happy
not to take on another major development in that arena. ASM is
exceedingly unforgiving to coding mistakes, and debugging it has
been some of the most ardious mental work I have ever done. I
prefer to avail myself of tools that help make the programmer's
life a bit easier, and not rail against something because it does
not fit in with my personal choices.

------------------
Old Navy Chief, Systems Engineer, Systems Analyst, now semi-retired