flat assembler
Message board for the users of flat assembler.

Index > Heap > bus data transfers

Author
Thread Post new topic Reply to topic
b1528932



Joined: 21 May 2010
Posts: 287
b1528932
Whats the ammount of data transfer cpu can perform in 1 bus request?

for example, instruction lock cmpxchg16b must read 16 bytes at once (because lock require write right after read to unlock, otherwise hang).

does cpu has variable number of bytes requested?
can i send on bus 'give me X bytes', where x is 1,2,4,8,16?



another problem is what happens later. does cpu wait for some kind of acknowlegment in case of write? Does it wait for requested data in case of read?

Is it possible that if cpu will read too fast, memory or other hardware might not deliver data before cpu will use it? (resulting in using old data)



do in/out/ins/outs operate exactly as mov/movs, but on diffrent bus?
Post 22 Sep 2010, 14:02
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17352
Location: In your JS exploiting you and your system
revolution
b1528932: Every CPU is different in how it interfaces to the hardware. You have to check the specs for whatever CPU you are working with. Usually only the mobo/bridge-chip manufacturers need to know the details of precisely how to interface to the external buses of each CPU. Some CPUs have direct DDR interfaces, some require bridging chips etc.

Also don't forget about the cache, many things are hidden from the external buses by internal cache transfers.
Post 22 Sep 2010, 14:16
View user's profile Send private message Visit poster's website Reply with quote
guignol



Joined: 06 Dec 2008
Posts: 721
guignol
*to interface (with)
Post 22 Sep 2010, 17:27
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
Don't all (non-ancient) x86 CPUs transfer an entire cacheline at a time? (and yes, those do differ in length).
Post 22 Sep 2010, 20:45
View user's profile Send private message Visit poster's website Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4240
Location: 2018
edfed
a pig cannot give a horse.

when you code, don't care about special stuff like that, just code the faster code yu can, and after, try to optimise. but in fact, we rarelly optimise something ones it works. even in asm.
Post 22 Sep 2010, 22:09
View user's profile Send private message Visit poster's website Reply with quote
ouadji



Joined: 24 Dec 2008
Posts: 1081
Location: Belgium
ouadji
Quote:

but in fact, we rarelly optimise something ones it works. even in asm.
Sorry edfed, i'm not agree with this.
Even if it works, not to optimize Is impossible for me.
I can spend hours to seek a better code, or to find a better sequence of instructions. "The right instruction at the right place!" (and nothing else)
If my code works, it's just a first step ... it's the step where I am developing the algorythm without worrying me about the code used. Then, I optimize to the max, this step is very important too. I hate to use three instructions where I can do with only one ... I hate to have jumps in all directions ... i like only perfect code,
even if my code works already for a long time.

_________________
I am not young enough to know everything (Oscar Wilde)- Image
Post 22 Sep 2010, 23:02
View user's profile Send private message Send e-mail Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 2917
Location: [RSP+8*5]
bitRAKE
f0dder is correct as all* cases in the CPU read/write cachelines - best to optimize for cachelines - might even surprise you on some simple things. Not just optimal use of bus, also optimal use of cache. Wink

*Non-temporal instructions like MOVNTQ/MOVNTPS/etc. force the bus to do partial (i.e. slow) writes unless a whole cacheline is being written. So, this case still favors cacheline granularity.
Post 23 Sep 2010, 02:51
View user's profile Send private message Visit poster's website Reply with quote
b1528932



Joined: 21 May 2010
Posts: 287
b1528932
i rarely code now.

i used to produce more code in the past, but my knowleadge was inferior and every single time i was stuck somewere.

I get to conclusion, that first i must understand technology perfectly, and then i can be back into writing code. I want to understand only hardware and software logic, this is not infinite but very large area. I dont know when i manage to get it all, but i wont stop trying.

I must understand at 100% how does memory transfer work, what is the role of each chip on the mobo, and most importantly - know the history of computers from its beggining. Only then i will be able to write OS wich work on every single cpu from 50 years ago to 100+ of years into future.
Actually compatibility is the worst, because sooner or later i will need to have all hardware to run tests on. Implement same thing using diffrent designs based of avaiability... Or maybe i will just use oldest possible instructions, wich im guaranteed to be present everywhere?
Post 23 Sep 2010, 21:36
View user's profile Send private message Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 2917
Location: [RSP+8*5]
bitRAKE
Seriously, choose your target and follow through until you reach your goal. If your target is everything then your result will be nothing*. The easiest way is to let others choose your goal then just fill in the blanks, or tell them it is not possible (what I'm doing here). The harder thing is to outline what you want and slowly make it a reality - driving forward through those times when you're 'stuck'. (I do that, too.)

Sometimes it means asking for help (what you are doing here), or walking away from it for some time and coming back to it. Even with inferior knowledge I bet you have some ideas that are good and just need time to become a reality. Inspiration is a spark not to be found in history or the idea that you can ever understand something 100%. (Okay, maybe sometimes in history.)

I don't feel you want to write CP/M for current processors. Maybe, I'm completely miss-reading you, and you're goals are academic in nature. Aiming for the least-common-denominator doesn't seem like a successful strategy. Anyhow, get your ideas down and take the steps needed - however small they might appear to be. Code and it will come!

I learnt to program from BASIC and LOGO. Very simple general rules: break idea into a sequence of steps (linearize); use pattern recognition to reduce number of unique steps (folding); repeat and scale. Later I learned the names for the concepts I was already using: cohesion and containment. Cohesion maximizes the internal interface reuse of a step. Containment reduces the external interface of a step. Together they dictate software topology - which steps to break apart and which steps to combine.

*Barring the rare case of you developing some new technology that becomes everything.
Post 24 Sep 2010, 02:58
View user's profile Send private message Visit poster's website 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 can attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on YouTube, Twitter.

Website powered by rwasa.