Author Topic: assembly conversions  (Read 6693 times)

0 Members and 1 Guest are viewing this topic.

JRS

  • Guest
Re: assembly conversions
« Reply #30 on: August 23, 2020, 11:22:14 AM »
Code: ASM
  1. dim as long a
  2. asm
  3.   mov eax,[a]
  4.   inc eax
  5.   mov [a],eax
  6. end asm
  7.  

I forget that FB is O2's mum. Uncle SB seems to have had an influence.

Brian Alvarez

  • Guest
Re: assembly conversions
« Reply #31 on: August 23, 2020, 01:51:39 PM »
 Charles, i am experiencing a weird issue for which (yet again) i have no explanation. This is some output of the sample tokenizer i made:

Code: [Select]
-----------------------
  TOKEN===>INCLUDES
PEEK ADDRESS: 6216514
  LENGTH => 8
  strptr(contents(12)) => 6212828   ' 12 is the include file #12.

-----------------------
 RECALL===>uriBASIC
PEEK ADDRESS: 6216514
  LENGTH => 8
  strptr(contents(12)) => 6212828   ' 12 is the include file #12.

 The top portion is output during the parsing step, it correctly displays the parsed word, its address and its length. It also displays the address of the array's string element that holds the data.

 The bottom portion is output after about 430000 words have been parsed. It displays incorrectly the parsed word, but its address and its length are correct. It also displays the address of the array's string element that holds the data using strptr, and apparently the array's string element address is still the same.

 The addresses and lengths of the indexed words are retained correctly... but the parsed word differs even if the string is still in the same address...

 The parsing and the displaying is performed in a different function, could it be that Oxygen is doing something funny to the string even though it's address (and AFAIK its contents) is the same?

 By the way, this is what my PEEK$ function looks like:

FUNCTION PEEK$(sys src, int l) as string
    STRING b = news(l)
    copy(strptr(b), src, l)
    return b
END function
 
« Last Edit: August 23, 2020, 02:04:18 PM by Brian Alvarez »

JRS

  • Guest
Re: assembly conversions
« Reply #32 on: August 23, 2020, 03:07:53 PM »
Long shot:

How does available memory look like? (leak?)

Brian Alvarez

  • Guest
Re: assembly conversions
« Reply #33 on: August 23, 2020, 05:22:49 PM »

No apparent memory leaks... but i also suspect there could be one. Im still baffled at how the addresses match, i can print the strings... yet, copy brings the text from god knows where...

I will find it.

JRS

  • Guest
Re: assembly conversions
« Reply #34 on: August 23, 2020, 06:14:44 PM »
This may be unrelated but O2 would randomly leave cells in the IUP matrix control blank for no reason. When I switch to VB6 my grid problems went away.

Charles Pegge

  • Guest
Re: assembly conversions
« Reply #35 on: August 23, 2020, 06:52:40 PM »
The original PB tokenizer code looks a bit strange. How does it exit the tokenize function?

Does it work by accident?

JRS

  • Guest
Re: assembly conversions
« Reply #36 on: August 23, 2020, 07:59:58 PM »
Quote
Does it work by accident?

Dead Code Call

Brian Alvarez

  • Guest
Re: assembly conversions
« Reply #37 on: August 24, 2020, 06:03:43 AM »
The original PB tokenizer code looks a bit strange. How does it exit the tokenize function?

Does it work by accident?

 Yes, it was unfinished. I have a more complete one now, i will post it later today.

 Edit: I am finding very interesting stuff! Ill upload this in a few days. :D
« Last Edit: August 25, 2020, 07:25:58 AM by Brian Alvarez »

Brian Alvarez

  • Guest
Re: assembly conversions
« Reply #38 on: August 25, 2020, 08:16:41 AM »
 Well, i think i have finally debugged it completely and I am runnning some benchmarks of Oxygen Vs PowerBASIC.
Both perform perfectly fine and VERY fast, but I think there is still space for improvement in the Oxygen conversion.

 Here are the preliminar results (before optimization):

Code: [Select]
Compiled with: PowerBASIC for Windows 32bits
-----
 Word Count:  399998
Files Count:  65
 Start Time:  919284250
   End Time:  919284265
 Total Time:  15
-----

Compiled with: OxygenBASIC 32bits
-----
 Word Count:  399998
Files Count:  65
 Start Time:  919298890
   End Time:  919298921
 Total Time:  31
-----

Compiled with: OxygenBASIC 64bits
-----
 Word Count:  399998
Files Count:  65
 Start Time:  919308562
   End Time:  919308625
 Total Time:  63
-----

JRS

  • Guest
Re: assembly conversions
« Reply #39 on: August 25, 2020, 09:09:10 AM »
What are the 64 bit results?

🤔

Brian Alvarez

  • Guest
Re: assembly conversions
« Reply #40 on: August 25, 2020, 09:17:18 AM »
What do you mean? The're on the list, scroll to bottom.
« Last Edit: August 25, 2020, 11:48:17 AM by Brian Alvarez »

Brian Alvarez

  • Guest
Re: assembly conversions
« Reply #41 on: August 25, 2020, 12:27:34 PM »

 Well, the small speed penalty doesnt seem to come from the assebly conversion, it comes from the OPEN/CLOSE functions. My conversions seem to be slightly slower. :)

Charles Pegge

  • Guest
Re: assembly conversions
« Reply #42 on: August 25, 2020, 01:18:12 PM »
Are you basing your functions on fopen and fclose  ? (msvcrt.dll)

JRS

  • Guest
Re: assembly conversions
« Reply #43 on: August 25, 2020, 01:28:36 PM »
What do you mean? The're on the list, scroll to bottom.

Oops!

Didn't scroll the window. My bad.

Brian Alvarez

  • Guest
Re: assembly conversions
« Reply #44 on: August 26, 2020, 05:54:53 AM »
Are you basing your functions on fopen and fclose  ? (msvcrt.dll)

 No, i made my own functions using CreateFileA() and CreateFileW() directly.