flat assembler
Message board for the users of flat assembler.

Index > Linux > read file contents to array

Author
Thread Post new topic Reply to topic
Potato



Joined: 18 Apr 2020
Posts: 11
Potato
Hello,

I had a look at some of the examples with fasm, everything assembled corectly, and I had a tinker with the source. What I would like to do is write a program that I have already implemented in another language in fasm to see the difference in performance (vs Icon). But there is a bit of a gap in information available in how to do this.

What is the best book for fasm 64 bit linux programming - everything seems to be for windows or 32 bit systems.

Is there a 64 linux book/examples that can be easliy ported from another assembler to fasm that I can pilliage in a copy and paste frenzy?

Have been trying to write an program that will in x64 linux:

1. read in a text file that has a bunch of values (example 40,0,100,24,59,0,143,29) these files could have up to 4000 numbers in them.
2. take that data and fill an array
3. loop through the array (variable length depending on the amount of data read from the file).
4. write a file with the loop index array value with a string (example each line would be "i . + . data[$] . . ", \n

I get that reading, writing, opening, closing I can do via interupts.

I saw some issues with reading array values, is there a straight forward way I can account for the numbers being different lengths in printing? I saw there was the HeavyThing library of function that seem to offer some useful commands that can do this I think.

The plan is to have it so I can just fill a data file with numbers and then build a file that I can use in a csound score. I have written a program that does this in icon but I wanted to see how it would work in 64 bit linux.

Usually I would just butcher some rosetta code samples to do what I want, but there is not much info on x64 linux fasm.

Would this be better (more flexable) in fasmg?

Thanks.
Post 18 Apr 2020, 05:32
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17270
Location: In your JS exploiting you and your system
revolution
Reading and writing files on a disk is most likely going to be I/O bound unless there is a lot of intermediate processing.

For your case it appears there isn't much processing in the middle, it is just basic number conversion. So differences in performance might minimal or close to zero. And with at most 4000 numbers it would likely finish in a few milliseconds so accurate timing would be difficult.

fasm or fasmg would be almost the same except for how the macro language works. fasm will assemble faster in most cases. fasmg requires more support files.

You might be interested in redsock's exploration of file processing:
https://board.flatassembler.net/topic.php?p=212363#212363
Post 18 Apr 2020, 05:39
View user's profile Send private message Visit poster's website Reply with quote
Potato



Joined: 18 Apr 2020
Posts: 11
Potato
revolution wrote:
Reading and writing files on a disk is most likely going to be I/O bound unless there is a lot of intermediate processing.

For your case it appears there isn't much processing in the middle, it is just basic number conversion. So differences in performance might minimal or close to zero. And with at most 4000 numbers it would likely finish in a few milliseconds so accurate timing would be difficult.

fasm or fasmg would be almost the same except for how the macro language works. fasm will assemble faster in most cases. fasmg requires more support files.

You might be interested in redsock's exploration of file processing:
https://board.flatassembler.net/topic.php?p=212363#212363


Thank you for the info. I had a look through the assembly file and it answers a lot of the questions I had about the file management. With the additional error checking going on avoids a lot of potential headaches.

With the program I was hoping it would be flexable enough so I could use much larger data sets. As you say 4000 values is nothing, I think it was more of the challenge part and it opens the door to other things after. The harddrive being the limiting factors that very true and I should have thought of that.

After poking around the forum I found FDBG, such a useful tool for looking carefully at whats going on with the code. That program is going to make things way easier going forward.
Post 18 Apr 2020, 06:03
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
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 can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.